
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@sig.com 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.