Boost logo

Boost :

Subject: Re: [boost] Formal Review Request: Boost.Convert
From: Andrew Troschinetz (ast_at_[hidden])
Date: 2009-02-24 01:26:32

I missed your link to the source code before, but I went back and
found it. It has cleared up much confusion on my part. Though some
confusion yet remains.

On Feb 23, 2009, at 10:36 PM, Vladimir Batov wrote:

> You can do the following
> transform (
> s.begin(),
> s.end(),
> back_inserter(i),
> convert<int, string>(string(), -1)
> >> throw_t() >> std::hex);

I believe that says "convert to int from string, throw on error,
format as hex." But what does string() and -1 signify in that case?

And if you'll allow me to nitpick, it seems you've mixed up the order
of the function parameters here. Should it read as follows?

         convert<int, string>(-1, string())

And since it seems that -1 and string() serve no purpose here, can we
possible get a refinement to the following?

transform (
   convert<int, string>() >> throw_t() >> std::hex);

> 'convert_to' olny takes one argument and requires explicit TypeTo:
> unsigned i = convert_to(str).

Yes, sorry I mischaracterized the convert_to interface as you
currently have it.

I'm sure you meant to say here:

        unsigned i = convert_to<unsigned>(str);

Correct? That makes sense.

> 'convert_from' does deduce both but I do not think there is
> confusion here:
> unsigned u = convert_from("-1", 0);

I agree, somehow that syntax is clearer in my mind.

>> And if we change "convert_to" to "convert" it becomes even more
>> confusing.
> I am not sure I follow this. Which part of the below do you find
> confusing?
> unsigned u = convert<string, unsigned>("-1", 0);

Ah, see. Even within you're own post things have been confused. Above
we have:

        convert<int, string>(string(), -1) // <A, B> (B, A)

And now we have:

        convert<string, unsigned>("-1", 0); // <A, B> (A, B)

 From looking at the source code, it seems like the first one is just
a typo. But you see how easily things can get mixed up. I'd be happier
picking one interface, either convert or convert_to or convert_from to
keep things clear. Though that might make others unhappy, I don't know.

>>> // get "0xff" converted to int using as_hex functor
>>> int i = convert_to<int>("0xff") >> std::hex;
>> I thought operator>>() returns an istream? If there's precedent
>> somewhere where it doesn't return an istream, forgive my ignorance
>> please.
> As far as I am concerned, op>>() returns whatever we'd like it to
> return. IMHO it certainly is not the property of std::streams. You
> could have a look at std::bitset. I am sure we can find many more
> examples.

You're correct, of course. Sorry I phrased the question badly.
Operator >> can be made to do anything. It could be a bitshift
operation as you say. But when I see >> and std::hex on one line, my
mind immediately goes to streams because std::hex is a stream
manipulator. And in this case, the stream that's being manipulated
isn't exposed to the user, it's an implementation detail. Using stream
manipulators here may be nice, but it's a bit of a case of
implementation leaking into the interface. I'm not saying that's
entirely bad in this case because using stream manipulators does seem
to solve the problem nicely, but it is a bit weird (at least to me
anyway) seeing them used this way.

I could get used to this interface though, nice job so far. Thank you
for the effort.

Andrew Troschinetz
Applied Research Laboratories

Boost list run by bdawes at, gregod at, cpdaniel at, john at