Re: input formatted file
On Nov 27, 11:35 am, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
James Kanze wrote:
On Nov 26, 4:56 pm, "Jim Langston" <tazmas...@rocketmail.com> wrote:
"James Kanze" <james.ka...@gmail.com> wrote in message
[...]
That's boost::lexical_cast. Which is probably what I'd use if I
ever needed it. I'll admit that I never saw the utility of
boost::lexical_cast either. And I'm rather sceptical of using
iostream inserters and extractors for this, too.
Consider something like:
std::complex< double > z( 1.0, 0.0 ) ;
double x = boost::lexical_cast< double >( z ) ;
The result should obviously be 1.0.
There is nothing obvious about this.
There's nothing obvious about the fact that the complex number
1+0i should become simply 1 when converted to double? I'm not a
mathematician, but I don't see what else would be reasonable.
Your code will return 0.0,
and boost::lexical_cast will raise some sort of exception.
And how would boost be wrong? Seems like the RightThing(tm) to
do in this case.
I don't know. It might be the right thing to do for something
like complex<double>(0.0,1.0), but here, I rather doubt it.
Either way, it highlights the crux of the problem: the behavior
of the conversion is really randomly defined, with no regard to
what might be relative semantics. It's a case of doing
something because you can, not because it has any meaning.
IMHO, the example showcases both problems:
-- converting a type A to a type B makes no sense in
general---you have to define exactly what is meant, for each
case (What should std::complex< double >( 0.0, 1.0 )
return when converted to double?), and
-- whatever definition you use, the >> and << won't necessarily
do the trick.
(I wonder if this isn't some sort of larger anti-pattern:
providing a generic solution for a problem which doesn't have a
generic solution.)
I don't think that there is such an anti-pattern. Whether a
problem has a generic solution or not very much depends on how
you phrase it.
There's definitely an anti-pattern of defining generic solutions
when they're not appropriate. std::pair and boost::lexical_cast
being good examples.
E.g., the standard containers all overload operator< although
there is no natural order on sequences of type T even for
types T that have an ordered set of values. Nonetheless it
makes perfect sense to settle on an order for sequences so
that you can use them as keys in maps.
That's a bit different. One might argue that there is a design
flaw in requiring order where there isn't a logical order (e.g.
making map and set ordered). In this particular case, there are
pragmatic considerations involved as well, however.
It probably would have been cleaner if the standard containers
had only defined a specialization of less, rather than the
operator<. Arguably, < has a specific meaning which isn't
applicable here. (And that is really your argument: that
operator overloading has been abused.) But the results serve a
very definite pragmatic purpose. You may disagree with the
relationship between the operator and the semantics associated
with it (arbitrary ordering, for use in ordered containers), but
that doesn't mean that providing a generic solution for those
semantics is necessarily wrong.
As for the particular case of lexical_cast, I found good uses
of it. But I also have generic IO for pairs, sequences,
tuples, and so on because it makes perfect sense in the
context of my code-base to have such operations available.
Then lexical_cast provides convenient way, e.g., to initialize
data in small test programs like so:
matrix< double > A =
lexical_cast< matrix< double > >( "[ [ 1.0 0.2 ] [ 0.0 -1.9 ] ]" );
That conveys content much better than all alternatives.
Hmmm. I'd have thought a constructor taking a string or an
istream would be more appropriate. Otherwise, a generic
conversion to/from string might be something to consider; I
don't seen anything wrong generic toString() and fromString
functions, for example. To/from just anything, however, using
the string representation as an intermediary, is, however,
unnecessary genericity.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34