1. Be able to provide a default value w/o type deducing being a problem. (ie: making the interface unclear) 2. Have the same interface when used as a functor. 3. Be very explicit and clear about if you're getting throwing behavior or defaulting behavior.
I believe we achieved thses goals with int i = convert<string, int>(str); int i = convert_to<int>(str); int i = convert_from(str, -1); See below.
// get "5" converted to int (throw on error) int i = convert_to<int>("5")(throw_t());
So could I do the following?
vector<string> s; vector<int> i; transform (s.begin(), s.end(), back_inserter(i), convert_to<int, string>(throw_t()));
Pretty much. You can do the following transform ( s.begin(), s.end(), back_inserter(i), convert<int, string>(string(), -1) >> throw_t() >> std::hex); I.e. get throwing hex-formatting behavior.
// get "-1" converted to unsigned or else 0 unsigned u = convert_to<unsigned>("-1", 0);
In this case <unsigned> isn't necessary, type deducing kicks in and we could just as well write: unsigned u = convert_to("-1", 0);
No, it won't work. 'convert_to' olny takes one argument and requires explicit TypeTo: unsigned i = convert_to(str). 'convert_from' does deduce both but I do not think there is confusion here: unsigned u = convert_from("-1", 0);
Which reads to me as "convert to -1 from 0".
As you can see it reads convert *from* "-1" string.
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);
// 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.
But given that interface, what does the following mean?
int a, b, c; string d; int i = convert_to<int>("0xff") >> std::hex >> a >> b >> c >> d;
It surely looks gibberish to me. I am not sure about older version but with the latest version I do not believe it will compile.
I'm not married to my interface either, I was mainly just using this discussion as a sounding board. I'd like to see a really nice interface come out of it that addresses the points I made:
1. Be able to provide a default value w/o type deducing being a problem. (ie: making the interface unclear)
Do you find the following satisfactory or still have concerns: int i = convert<string, int>(str); int i = convert_to<int>(str); int i = convert_from(str, -1);
2. Have the same interface when used as a functor.
How about this: transform ( s.begin(), s.end(), back_inserter(i), convert<int, string>(string(), -1) >> throw_t() >> std::hex);
3. Be very explicit and clear about if you're getting throwing behavior or defaulting behavior.
Currently it is like this -- you provide a default, you get the defaulting behavior; you do *not* provide a default, you get the throwing behavior. Do you think it is sufficient? Still, we could do int i = convert<string, int, throw_t::yes>(str); It'd make the implementation leaner as well. But I suspect people won't like it. Best, V.