Review Request: Introduction of boost::string namespace and string-conversion functions
Based on the previous string-conversion-related discussion that revolved around lexical_cast (started with http://lists.boost.org/Archives/boost/2009/01/147013.php) and Dave's suggestion (http://lists.boost.org/Archives/boost/2009/02/147995.php) I would like to propose to create a new boost::string namespace where I'd expect all string-related functionality might be logically housed. Dave already mentioned that "Jeff Garland had a really nice set of proposed extensions to std::string that could live in the same space". My immediate interest/proposal in that namespace would be the string-conversion functionality. The basics of that functionality are currently handled by lexical_cast but need extended and unambiguously tagged as *string*-related conversions. During discussion I've got a strong impression that the majority of people, the lexical_cast author (Kevlin) and the maintainer (Alex) strongly favor leaving lexical_cast as-is and having a fresh start capitalizing on the past experiences. Therefore I'd like to propose the string-conversion functionality that'd be housed inside that mentioned boost::string namespace. This proposal of mine probably is not as conventional as I have no implementation code to show. That is because before committing to it any further (or dragging someone else into it) I would initially like to see if we can agree on 1) creating boost::string (or some other as descriptive name) namespace; 2) the interface for that proposed string-conversion functionality. After that I expect the implementation to be largely a technical issue.
From the user point the interface I'd like to propose might look like the following:
int i; std::string s; 1) int i_from_s = boost::string::to<int>(s); // throws 2) std::string s_from_i = boost::string::from<int>(i); 3) bool s_is_i = boost::string::is<int>(i); The above convert a string to an integer (#1), an integer to a string (#2) and check if conversion is possible (#3). #1 and #2 behave like lexical_cast currently does (throw on failure). #3 is a non-throwing check if #1 will succeed (to avoid handling an exception thrown by #1). For example, int i_from_s = boost::string::is<int>(s) ? boost::string::to<int>(s) // safe to request conversion : some-failure-value; I like to/from names as they allow me to read the code as it was merely English -- "string to int", "string from int". I expect string::to() and string:;from() to return a helper object as Dave suggested namespace string { template <class T> struct value { operator T() const; // throws iff parse unsuccessful bool good() const; // true iff parse will succeed ... }; } That'll allow as to make the interface consistent and extendable/chainable: 4) int i_from_s = boost::string::to<int>(s)(-1); The above is a non-throwing variation of #1 with the default value provided for failed conversion. 5) int i_from_s = boost::string::to<int>(s)(std::hex); 6) std::string s_from_i = boost::string::from<int>(i)(std::hex); The above is variations of #1 and #2 with the std::hex manipulator/formatter applied. That "chained" approach would allow to keep the interface consistency without sacrificing the flexibility. For example, 7) int i_from_s = boost::string::to<int>(s)(-1)(std::hex)(yet-another-manipulator); or add some other features when the need arises. Off the cuff the actual conversion might look something along the following lines: template<class T, class Char> boost::string::value::operator T() { std::basic_istringstream<Char> stream(string_); if (manipulators) stream >> manipulator_ >> ... >> value_; else stream >> value_; if (stream.fail()) if (no_default) throw something; else return default_value_; return value_; } Thanks, Vladimir.
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Vladimir.Batov@wrsa.com.au
I would like to propose to create a new
boost::string
namespace where I'd expect all string-related functionality might be logically housed.
Sounds right.
From the user point the interface I'd like to propose might look like the following:
int i; std::string s;
1) int i_from_s = boost::string::to<int>(s); // throws 2) std::string s_from_i = boost::string::from<int>(i); 3) bool s_is_i = boost::string::is<int>(i);
"is" is a poor name choice. It doesn't imply "can convert to." What's more, in order to arrive at the answer, I imagine one must actually try the conversion, so it would be better to provide a conversion function that returns false rather than throwing an exception on failure: if (boost::string::from<int>(s, i)) and if (boost::string::to<int>(i, s)) (I always put mutable parameters first in my code, but I can see an argument that they should follow the order of the types in the qualified call: string::to<int>(s, i).)
4) int i_from_s = boost::string::to<int>(s)(-1);
The above is a non-throwing variation of #1 with the default value provided for failed conversion.
That would read better as: int j(boost::string::to<int>(s).or(-1));
5) int i_from_s = boost::string::to<int>(s)(std::hex); 6) std::string s_from_i = boost::string::from<int>(i)(std::hex);
The above is variations of #1 and #2 with the std::hex manipulator/formatter applied.
This is interesting, but I don't like the new syntax relative to IOStreams. How about this: int l(boost::string::to<int>(s) >> std::hex); This implies a stream in the object returned from to<int>(s) on which the manipulator can be applied.
7) int i_from_s = boost::string::to<int>(s)(-1)(std::hex)(yet-another-manipulator);
That looks odd.
Off the cuff the actual conversion might look something along the following lines:
template<class T, class Char> boost::string::value::operator T() { std::basic_istringstream<Char> stream(string_);
if (manipulators) stream >> manipulator_ >> ... >> value_; else stream >> value_;
if (manipulators) stream >> manipulator1 >> ...; stream >> value_;
if (stream.fail()) if (no_default) throw something; else return default_value_; return value_;
That could be managed in derived value types based upon the signature of the calling function rather than using data members and conditional logic to react. _____ 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.
"Stewart, Robert" <Robert.Stewart@sig.com> wrote:
To: "boost@lists.boost.org" <boost@lists.boost.org> Sent: Thursday, February 12, 2009 12:05:39 AM Subject: Re: [boost] Review Request: Introduction of boost::string namespace and string-conversion functions
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Vladimir.Batov@wrsa.com.au
[snip]
4) int i_from_s = boost::string::to(s)(-1);
The above is a non-throwing variation of #1 with the default value provided for failed conversion.
That would read better as:
int j(boost::string::to(s).or(-1));
'or' is a keyword. Regards, Gevorg
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Gevorg Voskanyan
"Stewart, Robert" <Robert.Stewart@sig.com> wrote:
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Vladimir.Batov@wrsa.com.au
4) int i_from_s = boost::string::to(s)(-1);
The above is a non-throwing variation of #1 with the default value provided for failed conversion.
That would read better as:
int j(boost::string::to(s).or(-1));
'or' is a keyword.
Ah, yes. I'd forgotten that bit of the Standard of which I don't avail myself. Nevertheless, the idea is sound. Andrey Semashev suggested "with_default," though I think "or_default" might read better. 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.
Vladimir.Batov@wrsa.com.au wrote:
Based on the previous string-conversion-related discussion that revolved around lexical_cast (started with http://lists.boost.org/Archives/boost/2009/01/147013.php) and Dave's suggestion (http://lists.boost.org/Archives/boost/2009/02/147995.php) I would like to propose to create a new
boost::string
I would initially like to see if we can agree on
1) creating boost::string (or some other as descriptive name) namespace;
Could we come up with another name for the namespace? The string namespace looks too general to me and may potentially clash with std::string if "using namespace boost; using namespace std;" is written in the users' code. I suggest using boost::strings namespace (note the trailing 's'). In order to have the clear naming of the res of the interface, my further suggestions are bellow.
2) the interface for that proposed string-conversion functionality.
After that I expect the implementation to be largely a technical issue.
From the user point the interface I'd like to propose might look like the following:
namespace bs = boost::strings;
int i; std::string s;
1) int i_from_s = boost::string::to<int>(s); // throws
bs::to_string?
2) std::string s_from_i = boost::string::from<int>(i);
bs::from_string?
3) bool s_is_i = boost::string::is<int>(i);
I like the way it is.
The above convert a string to an integer (#1), an integer to a string (#2) and check if conversion is possible (#3). #1 and #2 behave like lexical_cast currently does (throw on failure). #3 is a non-throwing check if #1 will succeed (to avoid handling an exception thrown by #1). For example,
int i_from_s = boost::string::is<int>(s) ? boost::string::to<int>(s) // safe to request conversion : some-failure-value;
I like to/from names as they allow me to read the code as it was merely English -- "string to int", "string from int".
I expect string::to() and string:;from() to return a helper object as Dave suggested
namespace string { template <class T> struct value { operator T() const; // throws iff parse unsuccessful bool good() const; // true iff parse will succeed ... }; }
That'll allow as to make the interface consistent and extendable/chainable:
4) int i_from_s = boost::string::to<int>(s)(-1);
The above is a non-throwing variation of #1 with the default value provided for failed conversion.
5) int i_from_s = boost::string::to<int>(s)(std::hex); 6) std::string s_from_i = boost::string::from<int>(i)(std::hex);
The above is variations of #1 and #2 with the std::hex manipulator/formatter applied.
That "chained" approach would allow to keep the interface consistency without sacrificing the flexibility. For example,
7) int i_from_s = boost::string::to<int>(s)(-1)(std::hex)(yet-another-manipulator);
Everything looks fine with me, except that I would suggest using a more explicit syntax for the default value specification. Like this: boost::string::to<int>(s).with_default(-1);
on Wed Feb 11 2009, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
Vladimir.Batov@wrsa.com.au wrote:
int i; std::string s;
1) int i_from_s = boost::string::to<int>(s); // throws
bs::to_string?
The above is converting a string to an int, so to_string would be inappropriate. I.e. string::to and to_string are grammatically different.
2) std::string s_from_i = boost::string::from<int>(i);
bs::from_string?
Ditto. Plus, specifying int explicitly above is not only wasted, but error-prone.
3) bool s_is_i = boost::string::is<int>(i);
I like the way it is.
7) int i_from_s = boost::string::to<int>(s)(-1)(std::hex)(yet-another-manipulator);
Everything looks fine with me, except that I would suggest using a more explicit syntax for the default value specification. Like this:
boost::string::to<int>(s).with_default(-1);
boost::string::to<int>(s, _default=-1) ? see Boost.Parameter -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
on Wed Feb 11 2009, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
Vladimir.Batov@wrsa.com.au wrote:
int i; std::string s;
1) int i_from_s = boost::string::to<int>(s); // throws bs::to_string?
The above is converting a string to an int, so to_string would be inappropriate. I.e. string::to and to_string are grammatically different.
2) std::string s_from_i = boost::string::from<int>(i); bs::from_string?
Ditto.
Oh, I certainly meant in reverse.
Everything looks fine with me, except that I would suggest using a more explicit syntax for the default value specification. Like this:
boost::string::to<int>(s).with_default(-1);
boost::string::to<int>(s, _default=-1)
?
see Boost.Parameter
Yes, that's a good alternative.
On Wed, 11 Feb 2009 21:54:09 +0100, Andrey Semashev <andrey.semashev@gmail.com> wrote:
Vladimir.Batov@wrsa.com.au wrote:
Based on the previous string-conversion-related discussion that revolved around lexical_cast (started with http://lists.boost.org/Archives/boost/2009/01/147013.php) and Dave's suggestion (http://lists.boost.org/Archives/boost/2009/02/147995.php) I would like to propose to create a new boost::string I would initially like to see if we can agree on 1) creating boost::string (or some other as descriptive name) namespace;
Could we come up with another name for the namespace? The string namespace looks too general to me and may potentially clash with std::string if "using namespace boost; using namespace std;" is written in the users' code.
I didn't follow the discussion and thus wonder why a new namespace should be introduced at all. After all there is boost::algorithm in Boost.StringAlgorithms? If boost::string or boost::strings is introduced we have string algorithms in different namespaces (or is boost::algorithm then renamed?). If a new namespace should be introduced only for string conversions then IMHO boost::string and boost::strings are both too general (it sounds like they would have been more appropriate for Boost.StringAlgorithms). Boris
[...]
on Thu Feb 12 2009, "Boris Schaeling" <boris-AT-highscore.de> wrote:
On Wed, 11 Feb 2009 21:54:09 +0100, Andrey Semashev <andrey.semashev@gmail.com> wrote:
Vladimir.Batov@wrsa.com.au wrote:
Based on the previous string-conversion-related discussion that revolved around lexical_cast (started with http://lists.boost.org/Archives/boost/2009/01/147013.php) and Dave's suggestion (http://lists.boost.org/Archives/boost/2009/02/147995.php) I would like to propose to create a new boost::string I would initially like to see if we can agree on 1) creating boost::string (or some other as descriptive name) namespace;
Could we come up with another name for the namespace? The string namespace looks too general to me and may potentially clash with std::string if "using namespace boost; using namespace std;" is written in the users' code.
I didn't follow the discussion and thus wonder why a new namespace should be introduced at all. After all there is boost::algorithm in Boost.StringAlgorithms? If boost::string or boost::strings is introduced we have string algorithms in different namespaces (or is boost::algorithm then renamed?). If a new namespace should be introduced only for string conversions then IMHO boost::string and boost::strings are both too general (it sounds like they would have been more appropriate for Boost.StringAlgorithms).
We can always compose namespaces later with using-directives. Decomposing them is much harder ;-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Andrey Semashev wrote:
Vladimir.Batov@wrsa.com.au wrote:
Based on the previous string-conversion-related discussion that revolved around lexical_cast (started with http://lists.boost.org/Archives/boost/2009/01/147013.php) and Dave's suggestion (http://lists.boost.org/Archives/boost/2009/02/147995.php) I would like to propose to create a new boost::string
I would initially like to see if we can agree on
1) creating boost::string (or some other as descriptive name) namespace;
Could we come up with another name for the namespace? The string namespace looks too general to me and may potentially clash with std::string if "using namespace boost; using namespace std;" is written in the users' code.
And even worse - it would make it very hard to propose the utilities for inclusion in a future language standard. Using names that are already in namespace std is not a good idea, if you have such ambitions. Bo Persson
On Wed, Feb 11, 2009 at 11:54:09PM +0300, Andrey Semashev wrote:
Could we come up with another name for the namespace? The string namespace looks too general to me and may potentially clash with std::string if "using namespace boost; using namespace std;" is written in the users' code.
How about boost::text? * A quick search suggests it is unused; * It doesn't seem to clash with anything in std:: * To my mind it includes other text representations than std::string (e.g. std::rope, std::vector<char>); * It excludes other uses of std::string or std::vector<char>, for example using vector<char> as a replacement for vector<bool>. -- "He is strongly identified with rebels, you see, and very popular with rabbles. They will follow him and he will fight to the last drop of their blood." Chris Boucher, Blake's 7 D13 ‘Blake’ http://surreal.istic.org/ It's a kind of threat, you see.
Based on the previous string-conversion-related discussion that revolved around lexical_cast (started with http://lists.boost.org/Archives/boost/2009/01/147013.php) and Dave's suggestion (http://lists.boost.org/Archives/boost/2009/02/147995.php) I would like to propose to create a new
boost::string
namespace where I'd expect all string-related functionality might be logically housed. Dave already mentioned that "Jeff Garland had a really nice set of proposed extensions to std::string that could live in the same space".
[snip] I just wanted to add a general use case/requirement for such a collection of (conversion)facilities. IMHO, these functions need to integrate well with Spirit.Qi (parsing) and Spirit.Karma (generating), while this integration needs to be twofold: a) The boost.string facilities should be able to use Qi/Karma for conversion of arbitrary types b) Qi/Karma currently contain highly optimized conversion routines for numeric<-->string conversions (different integer and floating point types). I would like to see those low level conversion routines moved into Boost.String allowing Qi/Karma to use them. Regards Hartmut
Vladimir Batov wrote:
Based on the previous string-conversion-related discussion that revolved around lexical_cast (started with http://lists.boost.org/Archives/boost/2009/01/147013.php) and Dave's suggestion (http://lists.boost.org/Archives/boost/2009/02/147995.php) I would like to propose to create a new
boost::string
namespace where I'd expect all string-related functionality might be logically housed.
OK, but I'd like to suggest that we should avoid thinking of strings as being particularly "special" in any way. As far as possible we should write generic stuff that can work with any container<char>. This makes it easier to move to things like UTF8 strings, to work with raw char*s, etc. If we don't think that it's possible to make this new stuff generic we should think about why that is.
Dave already mentioned that "Jeff Garland had a really nice set of proposed extensions to std::string that could live in the same space".
I guess this is the link: http://lists.boost.org/Archives/boost/2006/07/107087.php
My immediate interest/proposal in that namespace would be the string-conversion functionality.
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. (Well, one thing that's wrong with it is that it treats strings as "special", rather than working with generic container-of-characters, per my first point...) Phil.
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. _____ 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.
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); 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); In terms of syntax the latter is clearly more concise; some might argue that it's too concise (i.e. cryptic), but I would say that these conversions and their C equivalents are sufficiently commonly used that users will quickly learn what they do. But apart from these syntax differences, are there any benefits to one version rather than the other? 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. Phil.
----- Original Message ----- From: "Phil Endecott" <spam_from_boost_dev@chezphil.org> To: <boost@lists.boost.org> Sent: Thursday, February 12, 2009 3:12 PM Subject: Re: [boost] Review Request: Introduction of boost::stringnamespace Re: Review Request: Introduction of boost::stringnamespace
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);
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);
In terms of syntax the latter is clearly more concise; some might argue that it's too concise (i.e. cryptic), but I would say that these conversions and their C equivalents are sufficiently commonly used that users will quickly learn what they do. But apart from these syntax differences, are there any benefits to one version rather than the other?
Generics :) Vicente
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.
on Thu Feb 12 2009, "Stewart, Robert" <Robert.Stewart-AT-sig.com> wrote:
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?
That's much more complicated, since you need to specify encoding as well. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Phil Endecott Sent: 12 February 2009 14:13 To: boost@lists.boost.org Subject: Re: [boost] Review Request: Introduction of boost::string namespace Re: Review Request: Introduction of boost::string namespace
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);
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);
In terms of syntax the latter is clearly more concise; some might argue that it's too concise (i.e. cryptic), but I would say that these conversions and their C equivalents are sufficiently commonly used that users will quickly learn what they do. But apart from these syntax differences, are there any benefits to one version rather than the other?
What about handling user-defined types like big integer and big floating point like NTL ZZ, quad_float, RR, and GMP equivalents? Hardware is unlikely to go beyond 128 bit FP or int, if that, so we need to think ahead about more accurate integer and floating-point types in software. Only the to_string and from_string apply here? NTL uses the ugly RR v; v = to_RR("12345.6789"); but v = from_string<RR>("12345.6789"); feels better. Views? Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com
on Thu Feb 12 2009, "Paul A. Bristow" <pbristow-AT-hetp.u-net.com> wrote: <snip massive quotation>
that it's too concise (i.e. cryptic), but I would say that these conversions and their C equivalents are sufficiently commonly used that users will quickly learn what they do. But apart from these syntax differences, are there any benefits to one version rather than the other?
What about handling user-defined types like big integer and big floating point like NTL ZZ, quad_float, RR, and GMP equivalents? Hardware is unlikely to go beyond 128 bit FP or int, if that, so we need to think ahead about more accurate integer and floating-point types in software.
Thanks, -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (12)
-
Andrey Semashev -
Bo Persson -
Boris Schaeling -
Daniel Hulme -
David Abrahams -
Gevorg Voskanyan -
Hartmut Kaiser -
Paul A. Bristow -
Phil Endecott -
Stewart, Robert -
vicente.botet -
Vladimir.Batov＠wrsa.com.au