Re: [boost] Formal Review Request: Boost.Convert

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 (
   s.begin(),
   s.end(),
   back_inserter(i),
   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