Re: [boost] [SoC][string_cvt] The proposal for string conversions library.

From: Jeff Garland (jeff_at_[hidden])
Date: 2006-05-01 00:28:38

On Mon, 01 May 2006 10:25:48 +0700, Oleg Abrosimov wrote
> Hello, boost
> 
> This is an idea of project for Google SoC2006 that I want to participate.
> The library is called 'string_cvt' – or “string conversions”, it 
> solves the problem of converting type to string and string to type 
> with minimal runtime and syntactical overhead.
> 
> It is a simple "call for interest" mail.

Hi Oleg -

Let me just say I believe there is a clear interest in this area, so I
encourage you to submit an soc proposal.  A few comments inline below:

> Idea for this lib was inspired by recent discussion on boost developers
> mailing list. The question under discussion was:
> Is lexical_cast<> tool good enough for TR2 or not?
> 
> A proponents of lexical_cast<> have a point that the main
> advantage of lexical_cast<> component is its usage
> simplicity and symmetry (angle braces are used in both cases):
> int i = lexical_cast<int>("1");
> string s = lexical_cast<string>(1);
> 
> Additionally, it looks like built-in casts, and it is considered as 
> a very cool thing.
> 
> On the other side, opponents of lexical_cast<> wants more 
> functionality that doesn't fit into simple cast-like usage like:
> 
> The requirements table.
> 1) controlling conversions via facets (locales)
> 2) full power of iostreams in simple interface.
>     All functionality accessible with iostreams
>     (through manipulators) should be accessible.
> 3) functor adapters to use with std algorithms
> 4) error handling and reporting. (what kind of error occurred?)
>     * optionally report failing without exceptions raising
> 5) best performance, especially for built-in types and for use in loops
> 
> The "Lexical Conversion Library Proposal for TR2" by Kevlin Henney 
> and Beman Dawes states, that: "The lexical_cast function template 
> offers a convenient and consistent form for supporting common 
> conversions to and from arbitrary types when they are represented as 
> text. The simplification it offers is in expression-level 
> convenience for such conversions. For more involved conversions, 
> such as where precision or formatting need tighter control than is 
> offered by the default behavior of lexical_cast, the conventional 
> stringstream approach is recommended."

I presume this is n1973?

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n1973.html

> It is clear that lexical_cast is not intended to address (1-4) 
> points in the list above, and even (5). For optimizing conversions 
> in loops you'll need to resort to stringstreams again.
> 
> I believe, that stringstreams are not the right tool for daily 
> string conversions job. We need a special and fully featured 
> solution, which addresses all issues in the Requirements table 
> above. My dream is that one has no need to fallback to C-style 
> solutions or to stringstreams anymore, just one consistent interface 
> for all string conversion needs. This proposal for Google SoC 
> project is an attempt to develop such a solution. The final 
> ambitious goal of this project is to make boost::lexical_cast<> 
> obsolete and replace it in TR2 with a new proposal. Regardless of 
> SoC, I’m going to develop such a library for boost, but the 
> participation in the Google SoC is important because otherwise it 
> would be hard to manage enough time to finish this library before 
> the deadline for TR2 in October.

One other proposal you should be aware of is Pete Becker's n1982 for simple
numeric to string conversions:

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n1982.html

Part of the synopsis:

 int stoi(string& str, int base = 10);
 long stol(string& str, int base = 10);
 unsigned long stoul(string& str, int base = 10);
 long long stoll(string& str, int base = 10);
 unsigned long long stoull(string& str, int base = 10);
 float stof(string& str);
 double stod(string& str);
 long double stold(string& str);
 string to_string(long long val);
 string to_string(unsigned long long val);
 string to_string(long double val);
 //...snip more....
 wstring to_wstring(long long val);
 wstring to_wstring(unsigned long long val);
 wstring to_wstring(long double val);

While this is a very C like proposal it fills a basic gap in C++ for basic,
high performance, (w)string to number conversions.  My understanding is this
the committee is pretty fond of this proposal -- perhaps someone that was in
Berlin can say more (Beman, Howard?).

> As a result of this project we would have not only fully documented 
> and tested library for string conversions, but full comparative 
> performance analysis would be made to ensure that there is no more 
> any need to fallback to some other solution.
> 
> There are short examples of intended usage of this library (for 
> those who are too busy to read the full proposal’s text)
> 
> // simple initialization usage:
> string s = string_from(1);
> int i = from_string(“1”);
> 
> // embedded in expression usage:
> double d = 2 + (double)from_string(“1”);

I think having a C-style cast is a no no. I assume: 

  double d = 2 + static_cast<double>(from_string(“1”));

would work as well?

>...snip lots of good details...
 
One thing I didn't see address in your proposal is how 'user defined types'
can be handled.  So, for example, with lexical cast I can do this:

 using namespace boost::gregorian;
 date d(2006,May, 1);
 std::string ds = lexical_cast<std::string>(d);

and this 

 std::string ds("2006-May-01");
 date d = lexical_cast<date>(ds);

This works because date has a defined operator<< and operator>>. You would
need to show how this would be done in your proposal to really compete with
lexical cast.  Also note that with updates to the date-time global facet, the
format of the date can be changed around, localized etc.  
 
> Till now I have a minimal working implementation of basic concepts proposed.
> 
> Possible mentors for this project could be authors of the “Lexical 
> Conversion Library Proposal for TR2” proposal - Kevlin Henney and/or 
> Beman Dawes.

I'm not sure Kevlin or Beman is available, but I'm certain we can find a good
mentor if the proposal is accepted.

Jeff