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

Subject: Re: [boost] [convert] Boost.Convert Library Review
From: Matthew Chambers (matt.chambers42_at_[hidden])
Date: 2011-05-02 12:46:41

On 5/2/2011 10:57 AM, Michael Fawcett wrote:
> On Mon, May 2, 2011 at 11:39 AM, Gordon Woodhull<gordon_at_[hidden]>  wrote:
>>
>> 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.
>
> I would also like to voice my support of Vladimir.  Parsing XML or
> properties files is tremendously slow using lexical_cast because of
> all the exceptions when all you want is a default value if something
> is missing.  We've been down this road before, discussing extending
> lexical_cast and it went nowhere for a decent reason.  So Vladimir's
> only choice was to make Convert, yet people are still voting No over
> this.
I was under the impression that it was the stringstream allocations rather than the exceptions. 
Unless you're generally throwing an exception for every single attribute or something.

I disagree with the "*_cast must take a single argument" reasoning. I don't see why a built-in cast 
shouldn't take optional arguments when the context is appropriate, which is precisely the case with 
lexical conversion. The name of the cast isn't unformatted_lexical_cast, it's lexical_cast. So it 
should be able to handle formatted integers (which are perfectly valid language constructs)! And if 
it sometimes needs additional arguments to do that properly, so be it. None of the built-in casts do 
anything nearly as complicated as lexical_cast, so it's inappropriate to extrapolate their 
limitation to a single argument to lexical_cast.

> Where non-stream-based conversions are required, lexical_cast is the wrong tool for the job, and so it won't be special-cased for such scenarios.
I also disagree with this 2005 assertion that the lexical_cast name (or API?) is inappropriate for 
non-stream-based conversions. I don't understand why lexical_cast can't (for technical reasons) be 
the "best_conversion" that Gordon alluded to. In 2005 there were political reasons that this didn't 
happen; it should be reconsidered since the author has resigned from maintaining it. Many of us use 
lexical_cast because of its "it just works" semantics. I expect many of us that care about 
performance have added the non-stream-based specializations in our local code - I know I have. And 
I'd probably do the same for locales if I had that requirement.

Sorry for reviewing lexical_cast instead of Vladimir's convert. :(

After reading the other reviews of Vladimir's library, I mirror Hartmut's summary:
> To summarize: I feel uneasy to suggest accepting this library as it covers
> functionality which in my opinion belongs into lexical_cast<> in the first
> place. It is a natural extension of lexical_cast's functionality and for
> this reason should be merged with lexical_cast instead of being accepted as
> a separate library. Having two stream based conversion libraries in Boost
> (which moreover while complementing each other, sometimes expose different
> behavior) does not make any sense to me.
>
> OTOH, the functionality exposed by convert is much needed and has to make it
> into Boost somehow.

It may be worth suspending this review pending a definitive discussion of lexical_cast's future 
because it covers so much of the same ground as lexical_cast. Has anybody ever studied what parts of 
boost have the most market penetration? I speculate that shared_ptr and lexical_cast are the top two 
but I'd like to see real numbers. I think Vladimir's contributions would get a lot more usage if we 
could squeeze at least some of it into lexical_cast. Perhaps lexical_cast could become a wrapper 
around convert (the latter providing an option for non-throwing behavior while the former maintains 
bad_lexical_cast). Both APIs should share the non-stream optimizations and might be able to share 
the locale/formatting interface modifications.

-Matt