$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.