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

For variations on error policy I add words like "try", "must" or "maybe" to the function name; similarly for hex and other variations.

That could well be a good approach even for Boost.Convert; it is somewhat in keeping with other suggestions.

Why should we try to find a "one size fits all" solution to this problem?

Doing something well and right is non-trivial. Furthermore, not everyone is familiar with things like ranges or lambdas, for example, so a library author can provide capabilities in ways other developers might overlook.

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. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

On 04.05.2011 2:47, Phil Endecott wrote:

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()); }

For variations on error policy I add words like "try", "must" or "maybe" to the function name; similarly for hex and other variations.

:/ ugly forget about std C library, its naming conventions and C's idioms in general. boost::lexical_cast<> (and std::stringstream), in comparison, support conversions from *any* IStreamable to *any* OStreamable, but your tool convert from raw char-representation to long only! Hundred steps back! for raw-to-int conversion you propose strtoi() name??? for raw-to-double strtod? ...and so on... this "approach" is useless in a generic code context you must use function overloading (with the sole *nice* name) instead of producing a large amount of ugly names that makes excess pressure on mind