Boost logo

Boost :

Subject: Re: [boost] [convert] Boost.Convert Library Review
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-05-02 13:01:14


Gordon Woodhull 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'm well aware of that. Still, there's been some discussion as to whether Kevlin is still the maintainer. If he abdicates (or has abdicated) that responsibility, then the new maintainer gets to decide the future of lexical_cast. Thus, there may yet be an opportunity to augment lexical_cast, which was my point.

> > 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.

Why?

_____
Rob Stewart robert.stewart_at_[hidden]
Software Engineer using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk