Re: [boost] Formal Review Request: Boost.Convert

Subject: Re: [boost] Formal Review Request: Boost.Convert
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-02-24 11:44:05

On Tuesday, February 24, 2009 4:26 AM
Vladimir Batov wrote:
> Rob Stewart wrote:

(Please get in the habit of attributing your quotations.  It makes things easier for the rest of us to follow.)

> > std::hex assumes some state in the stream for storing
> > that hexadecimal formatting
> > ... but it still requires the cooperation of the manipulators
> > to set the state and the formatting logic invoked later.
>
> Yes, and my expectation was/is that convert() (as
> lexical_cast) piggy-backs
> on that std::stream functionality. And I think we've achieved
> very decent
> results in that direction that many people would prefer to
> raw std::streams
> and lexical_cast.

I hadn't seen any commitment to doing so, but I favor it.  That offers the best reuse of functionality and knowledge.

> Discarding std::streams for formatting and building something
> similar from
> scratch based on Boost.Parameter is quite a task. I am not
> well qualified to
> take on such a task. Especially in a short timeframe. I am

I'm not sure why you're in such a rush.

> not even sure
> there is truly pressing need for that. I could look into it

I'm inclined to think there isn't, but I'm not sure what Andrey had in mind.

> without hurry
> next if convert() gets through the review.

I know you already requested a review, but that seemed woefully premature.

> > I'd still like to see a coherent set of requirements.
> > There are too many forces tugging on the concept
> > from what appear to be competing directions.
>
> I personally feel we've achieved all our immediate objections
> that I felt
> were important to people --
>
> 1. the default value,
> 2. no DefaultConstructibility,
> 3. throw/no-throw behavior,
> 4. simple/advanced failure checks,
> 5. formatting (even though only "uninteresting" std::stream-based),
> 6. locale.

This is the closest thing to a set of requirements I've seen.  What about the concern I raised early on about implicit conversions?  The ideal interface has the compiler deducing both the source and destination types to avoid implicit conversions of the source object to the source parameter and the conversion result to the destination object.

4) and 5) are incompletely specified.  What are the use cases?  What sort of formatting control is needed?  Does the current interface support them?  Without use cases specifying the desired usage pattern, it's hard to know whether the current interface is sufficient.  (The use cases, of course, lead to test cases.)

Was there a link to documentation on these requirements that I missed?

> In fact, I do not feel there are many forces pulling in different
> directions. The issues remaining are
>
> 1. if the existing interface could be improved and

What about Emil Dotchevski's desire for from_string() and to_string()?  Have those been dropped entirely?  I think it was Emil's intention that those functions be concerned with providing optimized conversions to/from string with only limited formatting support, but they required type-specific overloads.  I'm not sure those were to be, or could be, based upon IOStreams.  (I'm not sure the two can be reconciled, but I didn't want Emil's concerns to be dropped altogether.)

> 2. one major issue of deploying Boost.Parameter.
>
> As for #1 there always room for improvement. Having said that I feel
> something very laconic and unambiguous has come out of the

FYI, "laconic" is rarely used in modern American English.  (I can't speak for other variants.)  We use "concise" instead.

> discussion (even
> though it has left no stoned unturned of my original "vision").

That is typically the case with Boost!

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
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.