Re: [boost] [Conversion] Review

Subject: Re: [boost] [Conversion] Review
From: Jeroen Habraken (vexocide_at_[hidden])
Date: 2011-08-30 15:36:36

On 29 August 2011 18:57, Vicente J. Botet Escriba
<vicente.botet_at_[hidden]> wrote:
> Le 29/08/11 17:42, Antony Polukhin a écrit :
>>
>> 2011/8/28 Vicente J. Botet Escriba<vicente.botet_at_[hidden]>:
>>>
>>> Le 28/08/11 09:43, Antony Polukhin a écrit :
>>>>
>>>> * What is your evaluation of the design?
>>>>
>>>> It is simple and looks good. But consider the following situation:
>>>> lexical_cast<char>(1) and numeric_cast<char>(1) will produce output.
>>>> It must be documented, which cast will your library use in which
>>>> cases.
>>>
>>> The documentation of header<boost/conversion/std/string.hpp> Â includes
>>> "Include this file when using conversions from/to |std::string| via
>>> |lexical_cast|. "
>>
>> And that`s were the problems begin! If user included this header, all
>> his conversion will convert convert_to<char>(1) as lexical cast does?
>> And what if the user whants conversions, like numeric cast does?
>>
>> More examples: Two developers are working on different parts of
>> project. Developer #1 uses  convert_to<char>(1) in his code and wants
>> behavior like numeric_cast. He also uses some headers, which is
>> maintained by Developer #2. At one day Developer #2 includes
>> <boost/conversion/std/string.hpp> Â in one of his headers. And we get
>> really hard detectable errors!
>>
> I will remove the string conversion are required by others as there is no
> consensus on which conversion must be used.
> The library works for unrelated types for which there is a clear and normal
> conversion. There are a lot of cases where the conversion should be unique,
> but the library can not ensure that that two developpers would define the
> same conversion.

If the traits are moved to Boost.TypeTraits, Boost conversions are
moved to the respective libraries (both of which I support and believe
should be done regardless of the review results) and string
conversions are removed, then what's left of this library?

> This section
> https://svn.boost.org/svn/boost/sandbox/conversion/libs/conversion_ext/doc/html/boost/conversion/users_guide.html#boost.conversion.users_guide.tutorial.proto
> gives some hints on how the libraries could organize conversion so only one
> definition is included in a program.
>
>>>> There must be some tags, to allow user to choose, which conversion is
>>>> required. There are some dummy::type_tag tags in source code, but
>>>> looks like they are not used, and not documented!
>>>
>>> They are used to overload the conversion functions. The class is
>>> documented
>>> here
>>>
>>> https://svn.boost.org/svn/boost/sandbox/conversion/libs/conversion_ext/doc/html/boost/conversion/dummy/type_tag.html.
>>> This
>>>
>>> https://svn.boost.org/svn/boost/sandbox/conversion/libs/conversion_ext/doc/html/boost/conversion/users_guide.html#boost.conversion.users_guide.tutorial.how_to_specialize_extrinsic_conversions_
>>> tutorial section explains how to use it.
>>
>> I could not determinate, for what are this tags used from the
>> documentation.
>
> As said in the documentation they are used to overload the customization
> points.
>>
>> Can we use them, to call numeric_cast instead of
>> lexical_cast? Can we use them, to call Boost.Coerce instead of
>> lexical_cast? can we use them, to support some parameters for
>> Boost.Coerce?
>
> No. I don't know from where you can get this impression. As said in the
> documentation the library is not intendeed to manage with string conversions
> neither with specificities in numeric conversions. This features are already
> covered by other libraries.
>>
>>> Could you elaborate on how you see the library can use these tags?
>>
>> Some thing like this:
>>
>> convert_to<char>(1, numeric_tag);
>> convert_to<char>(1, coerence_base<16>);
>> convert_to<pair<char, char> Â >(make_pair(1,1), lexical_tag);
>> convert_to<double>(1); // We can also convert without tags
>>
> This could be a possibility, but IMO tags don't scale well in this case. You
> will need to tag each one of the leaves otherwise you will find cases that
> would not be covered by the interface.
>
> convert_to<pair<char, char> Â >(make_pair(1,1), make_pair(numeric_tag,
> lexical_tag));
>
> Instead of this the user can create wrapper classes that convey the
> intendeed conversion.
>
> convert_to<pair<char, char> Â >(make_pair(numeric_tag(1), lexical_tag(1)));
>
> We can now define that lexical_tag<T> Â convert to a type U using
> lexical_cast, and that numeric_tag<T> Â uses numeric_cast.
>
> The library is open to these kind of customizations, but this works only if
> the users stors the wrappers and don't need to build them explicitly before
> doing the conversion.
>
> Best,
> Vicente

Jeroen