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) 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? 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).
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 that. V.