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 (
> 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?
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
> I am not sure I follow this. Which part of the below do you find
> unsigned u = convert<string, unsigned>("-1", 0);
Ah, see. Even within you're own post things have been confused. Above
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
> 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
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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk