Re: [boost] [Conversion] Review

Subject: Re: [boost] [Conversion] Review
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2011-08-29 12:57:36

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.

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