Subject: Re: [boost] Formal Review Request: Boost.Convert
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2009-02-24 13:43:59
Sorry for the late reply, it's been a busy weekend. I'm glad to see that
others answered some of your questions.
Vladimir Batov wrote:
>> 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.
My initial post wasn't specifically about string-related conversions,
however, the main plot is still applicable.
Assume we want to make a numeric conversion, but we also want to detect
truncation and treat it as an error:
int i = 0xFFFFFFFF;
short j = convert< short >(i, throw_on_overflow_ = true);
Now, that kind of conversion could be handled by
Boost.NumericConversion, something like this (pseudocode):
BOOST_PARAMETER_KEYWORD(throw_on_overflow_)
template< typename ToT, typename ArgsT >
ToT convert_impl(ArgsT const& args)
{
bool throw_on_overflow = args[throw_on_overflow_ | false];
return numeric_cast< ToT >(args[source_], throw_on_overflow);
}
You can see that the convert_impl accepts a single arguments pack that
accommodates all named arguments passed to the "convert" function,
including the source value i, which has the implicit name "source_". You
can also see that the "throw_on_overflow_" keyword belongs to the
Boost.NumericConversion library, and Boost.Convert does not need to know
anything about it.
As for the "string<->numeric" conversions, the approach is the same with
one exception: such conversions can be made by Boost.Convert itself.
This means that Boost.Convert may introduce its own keywords to
customize the conversion (such as radix_, bool_alpha_, etc.)
One dark corner that needs to be settled in this scheme is to figure out
how Boost.Convert will decide which convert_impl should be called. This
needs to be thought about, however, I think, using a number of traits on
the source and target types, yielding some tag type to dispatch between
convert_impl functions would suffice.
> Secondly, I do not feel there is much conceptual difference between
>
> convert<string, int>(str, radix_ = 16)
> and
> convert<string, int>(str).radix(16) // 16 passed in differently
> or
> convert<string, int>(str) >> radix(16) // different op>>
> or
> 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?
Like I said, using manipulators is sufficient for string-related
conversions, but is pretty meaningless for other types of conversion.
You could implement your own manipulator-like modifiers even for other
conversions, but it would look unnatural and more complex than using
keywords. For example, here's how wstring->string conversion could look
like:
string s = convert< string >(ws) >> replace_non_convertible_with('?');
or:
string s = convert< string >(ws, replace_non_convertible_with_ = '?');
Personally, the latter looks more appealing to me.
> RE: algorithms
>
> I've extended convert to be used with algorithms as
>
> std::vector<string> strings;
> std::vector<int> integers;
> ...
> std::transform(
> strings.begin(),
> strings.end(),
> std::back_inserter(integers),
> convert<string, int>(string(), -1));
>
> No formatting. I feel it is the best I can do (well, so far).
Do you intentionally use the "convert" verb for the functor name?
Traditionally, functors and other classes use nouns in their names, like
"converter".