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