Re: [boost] [convert] Boost.Convert Library Review

Subject: Re: [boost] [convert] Boost.Convert Library Review
From: Gordon Woodhull (gordon_at_[hidden])
Date: 2011-05-02 11:39:01

On May 2, 2011, at 10:58 AM, Stewart, Robert wrote:
> If lexical_cast can be extended, then I think most of the features of this library should be made part of lexical_cast, but that would preclude the optimized conversions I suggested earlier (when one can forgo locales and manipulators).  Thus far, history has indicated that such changes are not welcome, making a library like Boost.Convert necessary.

Along with Vladimir, I'd really like to kill this line of reasoning.  Here's Kevlin's rationale, quoted in some earlier discussion.  (It seems to have disappeared from the lexical_cast documentation since then.)

http://lists.boost.org/Archives/boost/2005/04/84917.php
> - It is also worth mentioning future non-directions: anything that involves adding extra arguments for a conversion operation is not being considered. A custom keyword cast, such as lexical_cast, is intended to look like a built-in cast operator: built-in cast operators take only a single operand. 

I actually find that pretty convincing, although I'd like to see something that looks as close to lexical_cast as possible.

> That answer is a bit ambiguous, so let me try to be clearer.  If lexical_cast can be updated to address most, if not all of what Boost.Convert offers, then Boost.Convert should not be accepted.  In that case, a distinct library that offers a non-stream-based means to do conversions that improves performance might be desirable.  However, if lexical_cast won't be updated to include what Boost.Convert offers, then yes, Boost.Convert should be accepted, with due attention to suggestions and concerns raised during the review.

Note that performance concerns are out of scope of Boost.Convert.