|
Boost : |
Subject: Re: [boost] Formal Review Request: Boost.String.Convert
From: Vladimir Batov (batov_at_[hidden])
Date: 2009-02-18 04:45:03
> convert::to_string<wstring>,
> convert::to_integral<int, rounding::down>,
> convert::transcode_string<wstring, native_mbcs>, ...
How about
convert::to<wstring>
convert::to<int, rounding::down>
convert::to<wstring, native_mbcs>
I am serious. I actually like it. I understand you do not like my to/from
but you are almost there. By eliminating the repetition (as for
_string<wstring) we get a laconic and expressive (IMHO of course) interface.
No need for various to_string, to_integral, transcode_string, etc. We get
rid of the string namespace as well (it should be a plus isn't it?). So,
it'd be
int i = boost::convert::to<int>(str); // explicit 'int' type
int i = boost::convert::to(str, -1); // deduced 'int'
string s = boost::convert::to<string>(-1); // explicit std::string type
string s = boost::convert::to(-1, "failed to convert"); // deduced
std::string
wstring s = boost::convert::to<wstring>(-1); // explicit std::wstring
type
wstring s = boost::convert::to(-1, L"failed to convert"); // deduced
std::wstring
Can you meet me half-way? I'll "give" you the string namespace "back" and
you get to keep "_string" as spare for something else... looks like you get
two things :-)... in case I again embarassed myself with my English I am
trying to be humorous here... but I really think it might be a good way
forward. The code is pleasant to read (IMHO), it leaves plenty of room for
growth (like convert::to<int, rounding::down>). I really like it. All the
functionality above is already in place. All that is needed is to change the
namespace and get rid of the redundant convert().
> Although convert might allow mix-fix relatively nicely:
> convert("5").to<int>(), ...
It looks clever. However, with the default/failure parameter it will
probably be
int i = convert("5").to(-1);
Now it looks confusing... to me. Somehow I feel more comfortable with the
example further up.
V.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk