Boost logo

Boost :

Subject: Re: [boost] [lexical_cast] A suggestion
From: David Abrahams (dave_at_[hidden])
Date: 2009-02-08 17:44:09


on Sun Feb 08 2009, Gennaro Prota <gennaro.prota-AT-yahoo.com> wrote:

> David Abrahams wrote:
>> on Mon Feb 02 2009, Alexander Nasonov <alnsn-AT-yandex.ru> wrote:
>>
>>> Vladimir Batov <batov <at> people.net.au> writes:
>>>
>>>> With no volunteeres coming forward , I am considering extending the lexical_cast
>>>> interface as described below. Is there any chance of that change integrated?
>>> I'm againt this change. See my other messages in this thread for details.
>>
>> I am too. Vladimir, I believe the functionality you want is badly
>> needed, but it shouldn't be part of lexical_cast. lexical_cast is
>> conceptually simple and should remain that way.
>
> lexical_cast was at best an experiment. In some limited contexts
> a generic from_string and a generic to_string might make sense.
> But a generic from/to anything, using a string as intermediate
> representation, is something done just because it can be done,
> not because it is useful or meaningfully specified.

Yes, that's what I've been saying. I don't particularly like the idea
of lexical_cast, and trying to stretch it to cover cases it wasn't
designed for will just put more important functionality in that bucket.

> I quacke at the idea that it is being used in a mission-critical
> project.

IMO that's an overreaction, but anyway...

>> The proper interface for the functionality you seek should be
>> considered without reference to lexical_cast.
>>
>> In fact, if we put together all the badly needed functionality
>> that overlaps with lexical_cast, and give it appropriate
>> interfaces, I'm not entirely convinced that there would be
>> much use for lexical_cast anymore.
>
> There isn't really much use anyway. It gives no control over the
> format or, for that matters, over anything.

...I think you're just making my point for me.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk