Re: [boost] [Convert] Not a review

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