Converting a substring to Integer

[Kira Yamato]

I have a bunch of strings in a database that have in them a number I
want to extract.

Why not try to solve it at the source? At the database.

If Oracle, try

select to_number(
replace(
translate(COL,
'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ ',
rpad('#',26+26+1,'#'))
, '#')) as COL
from TABLE;

[...]

 

[Daniel T.]

Probably because that's not its role. But it's an interesting
suggestion---it should be possible to define a manipulator which
skips using a predicate.

template < typename Pred >
istream& ignore( istream& s, Pred pred )
{
char c = 0;
while ( s.get( c ) && pred( c ) )
{ }
}

More useful, probably, would be a manipulator which skips using a
regular expression.

Using a state-full predicate in the above would probably work for that.

 

[James Kanze]

James Kanze <[email protected]> wrote:

[...]

template < typename Pred >
istream& ignore( istream& s, Pred pred )
{
char c = 0;
while ( s.get( c ) && pred( c ) )
{ }
}

Which will extract one character too many. And you need either
something like:

template< typename Pred > std::istream& ignore( istream& s ) ;

for the interface, or the function should return some special
type, e.g.:

template< typename Pred >
Ignorer< Pred >
ignore( Pred p )
{
return Ignorer< Pred >( p ) ;
}

with the actual work being done in the >> operator of Ignorer<
Pred >.

Using a state-full predicate in the above would probably work
for that.

Not for the extended regular expressions of Boost. Those
require backtracking, and there's practically no way to
implement backtracking.

 

[Reetesh Mukul]

[...]

Probably because that's not its role. But it's an interesting
suggestion---it should be possible to define a manipulator which
skips using a predicate.

template < typename Pred >
istream& ignore( istream& s, Pred pred )
{
char c = 0;
while ( s.get( c ) && pred( c ) )
{ }
}

Which will extract one character too many. And you need either
something like:

template< typename Pred > std::istream& ignore( istream& s ) ;

for the interface, or the function should return some special
type, e.g.:

template< typename Pred >
Ignorer< Pred >
ignore( Pred p )
{
return Ignorer< Pred >( p ) ;
}

with the actual work being done in the >> operator of Ignorer<
Pred >.

Using a state-full predicate in the above would probably work
for that.

Not for the extended regular expressions of Boost. Those
require backtracking, and there's practically no way to
implement backtracking.

--
James Kanze (GABI Software) email:[email protected]
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

I think the Pred is a kind of Filter. This is conceptually similar to
boost::iostream's filter. Or we can develop stream_iterator (similar
to file_iterator) and use spirit (I think spirit2.0 has some similar
construct, though I have not used it). Or we can design things similar
to boost::asio's read_until. I think some other yet_to_become Boost
libraries are modelling IOs.

As Bjarne tells us that designing general purpose IO library is a
tedious work, even then, conceptions like filter (which are often
used) should have well defined theme. I do not know the whole picture,
but months ago an idea came to me that we can have filters like:-
1. regex_based_filter
2. xpressive_based_filter
3. spirit_based_filter ( I tried succesfully but not very cleanly, to
use read_until with spirit2.0. However, I could not do the same with
async_read_until.)
4. ...

What should be the fundamental guidelines for a progammer who has not
seen the world completely ? How C++ is approaching theoretical minimum
for io's ? Please explain.

 

[James Kanze]

I think the Pred is a kind of Filter.

Pred is a predicate. At least in my examples, but I'm pretty
sure that that is what Daniel meant it to be as well.

This is conceptually similar to boost::iostream's filter.

Which iostream filters. I'm somewhat familiar with boost's
filtering streambufs, which *use* a predicate (not are a
predicate). But that's a different idiom, used in different
situations. The goal here is to define a manipulator which
skips a separator. It is called at specific times in the code,
when a separator is expected. The goal of a filtering streambuf
is to filter all of the data in a file---one typical use (at
least in my work) is to strip comments from input.

As Bjarne tells us that designing general purpose IO library is a
tedious work, even then, conceptions like filter (which are often
used) should have well defined theme. I do not know the whole picture,
but months ago an idea came to me that we can have filters like:-
1. regex_based_filter
2. xpressive_based_filter
3. spirit_based_filter ( I tried succesfully but not very cleanly, to
use read_until with spirit2.0. However, I could not do the same with
async_read_until.)
4. ...

What should be the fundamental guidelines for a progammer who
has not seen the world completely ? How C++ is approaching
theoretical minimum for io's ? Please explain.

I'm not sure I understand the question. The reason general
purpose IO is so difficult is that there are so many variations
in what people do with IO.

 

[Daniel T.]

[...]
Probably because that's not its role. But it's an interesting
suggestion---it should be possible to define a manipulator which
skips using a predicate.
template < typename Pred >
istream& ignore( istream& s, Pred pred )
{
char c = 0;
while ( s.get( c ) && pred( c ) )
{ }
}
Which will extract one character too many. And you need either
something like:
template< typename Pred > std::istream& ignore( istream& s ) ;
for the interface, or the function should return some special
type, e.g.:
template< typename Pred >
Ignorer< Pred >
ignore( Pred p )
{
return Ignorer< Pred >( p ) ;
}
with the actual work being done in the >> operator of Ignorer<
Pred >.
More useful, probably, would be a manipulator which skips
using a regular expression.
Using a state-full predicate in the above would probably work
for that.
Not for the extended regular expressions of Boost. Those
require backtracking, and there's practically no way to
implement backtracking.

I think the Pred is a kind of Filter.

Pred is a predicate. At least in my examples, but I'm pretty
sure that that is what Daniel meant it to be as well.

But a state-full predicate can store earlier characters and thus do any
backtracking that may be required.

struct Pred {
char last;
public:
Pred():last(0) { }
bool operator()( char current ) {
if ( last == ',' && current == ' ' )
result = true;
last = current;
}
};

The the above class and the ignore function I posited earlier, one could
search for ", " as the separator.

Granted, it can't put back any characters, but the idea is to scan
through the separator to the beginning of the next field, so that isn't
an issue.

 

[James Kanze]

But a state-full predicate can store earlier characters and
thus do any backtracking that may be required.

And what does it do if the characters don't match?

struct Pred {
char last;
public:
Pred():last(0) { }
bool operator()( char current ) {
if ( last == ',' && current == ' ' )
result = true;
last = current;
}
};

The the above class and the ignore function I posited earlier,
one could search for ", " as the separator.

Maybe. In much of the standard library, predicates can be
copied at will, and you'd need some sort of shared state for
something like this to work. In this case, however, I think
that the only copying must occur before the object is used, so
it should be OK.

Granted, it can't put back any characters, but the idea is to
scan through the separator to the beginning of the next field,
so that isn't an issue.

In this particular case. I thought we were talking about the
more general case of extended regular expressions, as supported
by Boost. (Strictly speaking, a true regular expression can be
converted to a finite automate, so no backtracking is necessary.
Most people expect extended regular expressions today, however,
and expressions involving a \(...\) generally do require an
implementation using backtracking.