Boost logo

Boost :

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?

> 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:

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at