Re: [boost] Review Request: Introduction of boost::string namespace Re: Review Request: Introduction of boost::string namespace

Subject: Re: [boost] Review Request: Introduction of boost::string namespace Re: Review Request: Introduction of boost::string namespace
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-02-12 10:55:39

From: Phil Endecott
> Stewart, Robert wrote:
> > From: Phil Endecott
> >>
> >> What do people think about the string/number conversions in N2408 ?
> >>
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2408.html -
> >> what is the status of that?)  Unless there's something wrong
> >> with that, I think we should build on it rather than re-inventing
> >> the wheel.
> >
> > Those are C-style.  The advantage of a template is that the
> compiler deduces
> > the correct implementation.
>
> The compiler can also deduce the correct implementation using
> overloading, which is what N2408 proposes for its to_string functions:
>
>      string to_string(long long val);
>      string to_string(unsigned long long val);
>      string to_string(long double val);

I didn't look at that part but, yes, overloading is also possible if the destination type doesn't vary.  A "w" prefix would work for wstrings, but what about other sequences of characters, if they're to be supported?

> For the from_string functionality we hit the standard problem that we
> can't type match on the type of the thing that the result is being
> assigned to:
>
>      short a = from_string(s);
>      float f = from_string(s);
>
> The compiler can't deduce the correct implementation; we have to tell
> it (unless we pass the result by reference I suppose).  We have a
> choice of template syntax:
>
>      short a = from_string<short>(s);
>      float f = from_string<float>(s);
>
> or the "C like" syntax proposed by N2408 (which I've just noticed
> doesn't mention short anywhere, breaking my example):
>
>      int i   = stoi(s);
>      float f = stof(s);

That's the part I was referring to.  Both the arguments and the results can be converted implicitly:

   short s(stoi(std::numeric_limits<long>::max()));

Better to leave argument deduction to the compiler, which also better supports size_t and other typedefs when moving among platforms.

Ideally, the result type should be deduced, too, so that implies passing a non-const reference argument for the conversion result rather than returning the value.  The value is that there can be no mismatch of function and types.  That also makes throwing and non-throwing variants more similar.

> Another feature of N2408 is that it supports number bases
> other than 10
> - for from_string conversions at any rate - using a defaulted
> parameter.  I would value this along with precision for
> floating-point types.

That's a reasonable feature, though the OP supported it via manipulators.

"from_string" and "to_string" highlight the specific goal of the OP's request, but can any sequence of characters be considered a "string" in that context?  The OP's "from" and "to" avoid that problem by deferring to the namespace name and benefit from being shorter.  In terms of standardization, however, it doesn't seem likely that there will be a dedicated namespace, so "from_<something>" and "to_<something>" seem better for that purpose.

I suspect there are potentially competing goals among the ideas in this thread.  The OP wanted a more generalized conversion tool that relies on streams, whereas N2408 is focused on more narrowly defined -- and optimized -- operations.

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