Jeff Garland:
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
Thank you for pointing me to the newer version of this proposal. Till now I was aware of n1803 one.
// 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?
yes, your version would work as well, but is too verbose ;-) the function from_string returns proxy object with templated cast to T operator defined. the purpose of explicit cast in the code above is to invoke the right cast operator. but I don't share the "no no" opinion against C-style cast in general. The Bjarne Stroustrup's book "The Design and Evolution of C++" has very good arguments in favor of this opinion: 1) They (C-style casts) are hard to understand because mix different meanings (static_cast/const_cast/reinterpret_cast) in one laguage construct; 2) provoke mistakes because of close to any combination of types have some legal meaning; // personally, I don't really understand what he mean by that :-( 3) it is hard to find them in code by eyes or by utilities like grep; 4) it complicates C and C++ grammar. now consider the code snippet again: double d = 2 + (double)from_string(“1”); 1) is it hard to understand what is going on here? from first glance? after explanation? 2) ??? 3) is it hard to find such constructs in code? {grep from_string} would help. 4) C-style casts won't disappear in any observable time because of interoperability with C. to conclude, I understand reasons against C-style cast in C++ and actually I don't remember when I've used it last time, but in this particular case I can not see any application of these reasons. I believe that in the case of "(double)from_string(“1”);" construct these reasons are just wrong. fill free to correct me, if I miss something. I like the "(double)from_string(“1”)" construct because it clearly says what is going on, it can be directly translated to: get double from string "1". Attractive! Isn't it?
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.
Of cause, you are right! The library proposed is a simple wrapper around std::iostreams and C-library functions, mentioned in n1982 proposal. It means that all functionality of iostreams (including UDT to string and vice versa conversions) are allowed (and encouraged, of cause). with the library proposed one can rewrote your example in the following way: using namespace boost::gregorian; date d(2006,May, 1); std::string ds = string_from(d); and this std::string ds("2006-May-01"); date d = from_string(ds); simple and symmetric.
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.
hope so Oleg Abrosimov.