Subject: Re: [boost] [Convert] Not a review
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2011-05-04 09:21:55
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,&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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk