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/ht... 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-tp365... Sent from the Boost - Dev mailing list archive at Nabble.com.