On 5/2/2011 10:57 AM, Michael Fawcett wrote:
On Mon, May 2, 2011 at 11:39 AM, Gordon Woodhull<gordon@woodhull.com> 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.
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
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. 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