|
Boost : |
Subject: Re: [boost] Boost.Convert. Take 2.
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-02-20 16:31:10
On 2/16/2014 3:56 PM, Vladimir Batov wrote:
> Addressed all three comments... I think. Checked in.
This looks good. I think you have successfully focused on what is needed
for a more flexible lexical_cast-like version this time.
>
> On 02/16/2014 02:58 AM, Edward Diener wrote:
>> 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.
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk