Boost logo

Boost :

Subject: Re: [boost] Boost.Convert. Take 2.
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-02-15 10:58:25


On 2/14/2014 2:16 PM, Vladimir Batov wrote:
> On 02/15/2014 01:46 AM, Edward Diener wrote:
>> On 2/13/2014 11:01 PM, Vladimir Batov wrote:
>>> ...
>>> Finished the docs. The whole thing is at
>>> https://github.com/yet-another-user/boost.xtra.
>>
>> Is the library called "xtra" or "convert" ?
> The library si still called the same "convert". Housed it in the
> "boost.xtra" dir to distinguish it from the real boost dir.
>>
>> The library should be in modular-boost structure. You have it in the
>> old SVN structure.
> OK. I'll look into it.
>>
>> Running b2 in the doc directory gives all sorts of errors because you
>> are still using the old SVN structure. So it is impossible to see the
>> documentation.
>
> Yes, did not check all (duh!) docs yesterday. Fixed now.

These lines in the doc look wrong. The expression 'convert<int>result'
does not look possible in C++. I think this should be
'convert<int>::result'.

convert<int>result r1 = boost::convert<int>(str1, cnv); // Does not
throw on conversion failure
convert<int>result r2 = boost::convert<int>(str2, cnv); // Does not
throw on conversion failure

I think you need to be precise in what a user-defined type needs to
provide in order to be 'convertible from' and 'convertible to' within
the convert framework. If that is too complicated in a design as a
general form of using convert, then limit the library to conversion
either to and from a std::basic_string<T> and specify what the single
type being converted from or to a std::basic_string<T> needs to supply
in order to work with convert. I actually see nothing wrong with such a
limitation if it is necessary to accomplish more easily what you
envision. I did not understand this information from the docs. Perhaps
you have worked this out but you need to explain it quite methodically.

I would also suggest that callables ( std::function types ) be used
instead of hardcoded function names when supplying user-defined
conversion functionality. This provides a much more flexible ability to
provide conversion for a user-defined type since the full retinue of
functor creation within the standard C++ library and from within Boost
can be used by the end-user to provide appropriate conversion routines.
Once you hardcode some conversion member function within a class you are
throwing out all this functor creation ability. Of course if such a
design is too complicated based on your own design for convert then stay
with what you currently have, but at least consider it if you understand
the power of C++ callables to provide user-defined functionality.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk