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

From: Oleg Abrosimov (beholder_at_[hidden])
Date: 2006-05-02 12:17:50

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.