Stewart, Robert wrote:
Phil Endecott wrote:
My view comes down to this: there are zillions of different ways of doing this (both syntax and semantics) and no solution can keep everyone happy (as evidenced particularly by the previous discussions). But that doesn't matter, because every single C++ programmer is capable of writing their own conversion functions that work exactly how they want them to work, if they have the right building blocks.
While your fundamental point is valid, there are flaws in your argument. First, many C++ developers, though perhaps not many willing to use Boost libraries, are not capable of writing appropriate and robust conversion functions, particularly when locales enter the picture.
Even when given the right building-blocks?
Second, I don't think there's any library in Boost that satisfies everyone. That isn't the goal.
The building blocks are things like C's strto*(), etc. Personally, I prefer thin wrappers like these ones:
template <typename ITER> long int strtol(ITER begin, ITER end) { ... }
template <int N> long int strtol(const char (&s) [N]) { return strtol(&s[0],&s[N]); }
inline long int strtol(std::string s) { return strtol(s.begin(),s.end()); }
You just argued, inadvertently, for a library like Boost.Convert. The wrappers you show above are flawed as there is no error checking.
The error checking is in the "..." that I elided.
Having written robust wrappers of that sort, I can tell you that the error checking is non-trivial. For example, only some of the strto*() functions clear errno on entry, so you need to do so first in the rest. Others have complex error semantics for detecting overflow. Thus, doing such things once and reusing them is wise.
Right. So, there's a case for improvements on strto*(). Let's do that.
Perhaps some of the lower-level "building blocks" would be useful, though - if things like strto*() are deficient.
I think those were present in Boost.Convert. I mentioned, for example, that a new_style cast function template could be a wrapper for what Vladimir wrote. That said, if Boost.Convert were to focus on being the building blocks library for conversions, or purposely exposed that part of the library for use by others with different preferences for the interface, it might fare better.
I agree. Regards, Phil.