Re: [boost] Boost.Conversion - pre review request

Subject: Re: [boost] Boost.Conversion - pre review request
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2011-07-09 03:57:39

Gordon Woodhull wrote:
> 
> Hi Vicente, all,
> 
>> I've been reworking the Boost.Conversion library
>> 
>> Documentation:
>> http://svn.boost.org/svn/boost/sandbox/conversion/libs/conversion_ext/doc/html/index.html
>> Sandbox :http://svn.boost.org/svn/boost/sandbox/conversion/
> 
> 
>> Description:
>> Boost.Conversion manages with generic extrinsic conversion between
>> unrelated
>> types. These conversion can be seen as implicit or explicit conversions.
> 
> I am excited to manage the Conversion review at the end of August.
> 
> It may be simple enough for us to say "extrinsic type-to-type conversion"
> since we both participated in the Boost.Convert review and have all those
> distinctions in mind...
> 
> But it might be confusing to potential reviewers and followers of Boost
> that in other "little c" conversion news this year:
> * lexical_cast has received a new maintainer who is adding optimizations
> for type-to-type which overlap with Conversion
> * Vladimir Batov's Boost.Convert was withdrawn.  I think it's fair to Ed
> Diener's excellent review report [1] to say that the library was not
> acceptable in its current form not because it didn't have the right
> features, but mostly because of syntax problems.  And because of confusion
> that its scope overlapped with lexical_cast, which I'm trying to avoid in
> the upcoming review!
> * Jeroen Habraken is working on a Boost.Coerce library [2] which does more
> runtime-efficient string-to-type and type-to-string conversion using
> Spirit.
> 
> One clear distinction is that the proposed Boost.Conversion is not
> concerned with the special cases of string-to-type and type-to-string.  It
> provides a general framework for type-to-type conversion and will defer
> string conversions to lexical_cast or coerce depending how it is
> configured.  
> 
> IMHO lexical_cast is not the appropriate generic function to use for
> type-to-type conversion (when there is no text involved), and I am
> managing the review to evaluate whether Boost.Conversion is the right
> solution.  
> 
> Boost.Conversion learns from the use cases that were presented by Vladimir
> Batov in Boost.Convert and its review, and IIUC it now provides all the
> behaviors that were not string-specific, without the syntax problems. 
> Obviously, that also means no operator<<, so there's no way to specify
> formatting options if text is involved.  (Jeroen, if you're reading this,
> can you convert to/from e.g. hexadecimal with Coerce?)
> 
> So, Vicente, let's go over the Scope section of the documentation, quoted
> in your message.  This helps a lot, but it should also include comparisons
> and interactions with the libraries listed above, as well as
> Boost.NumericConversion.
> 

Youa are right Gordon. I will update the introduction to state clearly these
facts.

>> The conversion operator can not be overloaded with a free function on
>> C++.
>> In the past, there were some request to been able to overload the @c
>> static_cast operator []. The author thinks that the language would be
>> more
>> uniform if this extrinsic overload would be possible.
> 
>> 
>> The new operators
>> could take the following form
>> 
>> operator Target(const Source& val);
>> 
>> explicit operator Target(const Source& val);
>> 
>> The assignment operator could also be overloaded by a free function with
>> some limitations as described in []
>> 
>> Target& operator=(Target&, Source const&);
>> 
>> Boost.Conversion tries to provide a library emulation for this missing
>> feature and shows some needed workarounds that are needed to take care of
>> the current C++ semantics.
> 
> Okay, so it is a library demonstrating the usefulness of a possible
> language feature.  However, your intro should also argue the library's 
> usefulness up until C++20.  :-)
> 

:). Yes, again you are right. Even if the library design is guided by these
possible/missing language  features and I try to be as close as possible of
how they could behave, I expect the library would be useful by itself. I
will try to make this more evident.

>> In order to provide the needed functionality, two type traits are
>> mandatory
>> is_constructible and is_assignable. The library provide a first
>> implementation of these type traits that works on compilers providing
>> some
>> specific features. The idea is that these type traits should be added to
>> Boost.TypeTraits. 
> 
> Are they needed simply to enable/disable the corresponding function in
> Conversion, or does it also affect the behavior?
> 

When we are not able to use these traits we are not able to define the
correct default behavior.
The library could work without these traits and don't using SFINAE but some
features can not be provided.

>> When we don't have an automatic way to detect these traits, the library
>> provide specialization for some std and boost types. If you agree the
>> library could provide the specializations for all the standard types and
>> optionally for some Boost types.
>> 
>> User working with compilers not supporting the definition of these
>> traits,
>> or users that need to make their code portable, will need to specialize
>> these traits by hand for his types.
> 
> All good, but it probably doesn't belong in the intro. 
> 

OK. I raised the issue here also to signal that if the library is accepted,
these traits should be moved to the TypeTraits library and that I'm ready to
work on this if John agree on the the fact that we should need to provide
specific specializations for a lot of types on the standard and Boost for
those non-conforming compilers.

>  As a library user I presume you will provide support for a good number of
> compilers in the best way you see fit.
> 

With the specialization of the is_constructible and is_assignable on
compilers that doesn't allow to detect them the library should work
correctly on compilers supporting SFINAE. I would like to know about how the
library is working on Intel, Sun and IBM compilers to which I have no
access. 

>> The review dates are 20th to 29th August. I would like to have some
>> feedback
>> before the review so I can have some time to make the library review
>> ready.
> 
> I hope this is helpful and I'll provide more detailed feedback soon.
> 
> 

Thanks,
Vicente

--
View this message in context: http://boost.2283326.n4.nabble.com/Boost-Conversion-pre-review-request-tp3650286p3655758.html
Sent from the Boost - Dev mailing list archive at Nabble.com.