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, Im 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 proposals 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