Subject: Re: [boost] Formal Review Request: Boost.Convert
From: Vladimir Batov (batov_at_[hidden])
Date: 2009-02-22 05:04:50
>> I looked a Boost.Parameter and will certainly try using it somewhere. My
>> hesitation with it for boost::convert is I am under impression that the
>> set of acceptable parameters (radix_, etc.) has to be predefined and
>> therefore cannot be extended by the user when formatting like
>> "convert(str) >> std::hex" seems more flexible.
> You can add new keywords as needed.
Where can I add those "new keywords" to? If it is into convert(), then I do
not feel it is appropriate as for every user "needed" will be different and
I cannot see convert() collecting *all* those "needed" keywords from every
user on the globe.
> The point is that the underlying conversion mechanism can support a subset
> of these keywords, specific to the conversion domain. This way it will be
> a non-intrusive extension.
I cannot understand how it can be a "non-intrusive extension" if every new
keyword needs to be stored/registered *inside* convert<string, int>...
unless I misunderstand something. With manipulators (however clumsy they
are) convert<string, int> knows nothing about std::hex. Still, when std::hex
is plugged in, we get 0xFF. How do you do that with "radix_"? The keyword
has to be registeded with convert<string, int> and then convert<> needs to
apply that somehow.
Secondly, I do not feel there is much conceptual difference between
convert<string, int>(str, radix_ = 16)
convert<string, int>(str).radix(16) // 16 passed in differently
convert<string, int>(str) >> radix(16) // different op>>
convert<string, int>(str) >> std::hex
The difference is that in #1 convert() has to handle "radix_" itself and in
#4 convert() knows nothing about std::hex. Am I missing something?
I've extended convert to be used with algorithms as
convert<string, int>(string(), -1));
No formatting. I feel it is the best I can do (well, so far).
> convert<string, short >(0xFFFFFFFF, throw_on_out_of_range_ = true)?
Looks certainly tempting. However, I do not believe it is achievable. For
that to happen every parameter (like throw_on_out_of_range_) needs to be
integrated into, say, convert<string, int> and then its value stored to be
re-applied for every entry during traversal. Far too expensive.
convert<string, type> has already grown beyond anything I ever imagined. I
might well not understand what you are advocating. Can you put together some
kind of proof-of-concept code for me to better understand how you want to do