$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [lexical_cast] A suggestion
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2009-02-09 15:46:48
My reply may be too late for the discussion, but I'll answer anyway...
David Abrahams wrote:
>>> That's not my concern.  My concern is that I don't think lexical_cast is
>>> a particularly good interface for its main uses, which could be thought
>>> of as "to-string" and "from-string."
>> I disagree. lexical_cast was designed to be simple to use, and I think it does it very
>> well. The "to-string" and "from-string" conversions, in their simple form, are just
>> corner cases. 
> 
> Eh?  What other uses has it got?!
To convert objects of different types between each other. I don't know 
if conversion between types that are not strings is widely used or not. 
Conversions between custom and fundamental floating point types come to 
mind as an example.
>> If I want to simply parse an int, I don't want to make up a Spirit
>> grammar for that or even use scanf. 
> 
> scanf is *way* lighter weight that lexical_cast.
It may be lighter in terms of implementation and speed, but certainly 
not in terms of interface clarity and safety. And anyway, lexical_cast 
can potentially be faster than scanf, if it is optimized the way it was 
for the "to-string" conversions.
>> I need a C++-style of strtol, which is safe in
>> terms of buffer allocation and types. 
> 
> So write that.
> 
>> This is what lexical_cast tries to achieve and it does, to some
>> degree. I don't know of any other tools that come this close to this
>> goal, neither in Boost, nor outside of it.
> 
> So write one (just my opinion).  lexical_cast means something very
> strange and overly-general, and we should write something targeted at
> the real-world uses people actually have.
I'm quite happy with lexical_cast, except for this default-value issue. 
Why would I write something new?
>>> I just don't think lexical_cast is the interface we need for most
>>> convenient string conversions.
>> Do you have a better interface in mind?
> 
> It would take some thought and discussion to perfect, but just off the
> top of my head, I'd want something like this:
> 
> namespace str
> {
>   template <class T>
>   struct value
>   {
>       operator T() const;  // throws iff parse unsuccessful
>       bool parsed() const; // true iff parse succecssful
>       ...
>   };
> 
>   template <class String, class T>
>   string::value<T>
>   string::as<T>(String const&);
> 
>   template <class String, class T>
>   typename enable_if<is_integral<T>, string::value<T> >::type
>   string::as<T>(String const&, unsigned base);
> 
>   template <class T>
>   std::string
>   to_str(T const& x);
> 
>   template <class String, class T>
>   String
>   to_str(T const& x);
> }
This does look pretty much like lexical_cast, a bit extended for string 
conversions, though.
I'm not against a better support for parsing or formatting in Boost. 
However, in case of simple needs, I think the potential of lexical_cast 
is not yet exhausted. Adding another library with so much overlapping 
functionality may confuse users.