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".