Re: [boost] [lexical-cast] version of lexical_cast in 1.46.1 is quite older than in trunk

Subject: Re: [boost] [lexical-cast] version of lexical_cast in 1.46.1 is quite older than in trunk
From: Jeroen Habraken (vexocide_at_[hidden])
Date: 2011-04-07 15:22:37

Hi,

On 7 April 2011 11:19, Vladimir Batov <vbatov_at_[hidden]> wrote:
>> ----- Original Message ----- From: "Vicente BOTET"
>> <vicente.botet_at_[hidden]>
>>>
>>> ... the Convert proposal sitting
>>> in the queue and getting ready for the review this month. I'd suggest
>>> anyone
>>> interested in additional lexical_cast features to have a look the the
>>> proposal
>>> if it already satisfies your needs. If not, then it's most definitely
>>> open for
>>> improvements/extensions/ideas/etc.
>>
>> It will be great to have a performance comparison between your library and
>> lexical cast (with a without the proposed modifications) as one of the
>> major
>> concerns of your library were to provide an interface that performs better
>> than lexical_cast.
>
> As I understand the main goal of the Convert library was to provide richer
> interface (or so I understood). Namely, to support configurable throwing
> behavior, locale, formatting and ability to extend if/when needed.
> Therefore, quite a bit of effort was put into working out the framework, the
> interface. In that light at this stage I feel that trying to address
> performance in Convert would be somewhat premature. Consequently, I do not
> expect the Convert library to do to/from-string conversions any better or
> worse than lexical_cast as at present Convert uses the same
> std::stream-based engine for those conversions. Having said that I do
> believe that performance needs to be addressed at some point and I am
> currently leaning towards deploying Spirit facilities to do that. If anyone
> has better suggestions, implementations, I do not see anything stopping them
> from incorporating those improvements into Convert. Obviously, before we go
> ahead doing that we have to find out if that library has any future to begin
> with.
>
> Best,
> V.

You've hit the nail on the head there I think. The lexical_cast author
has always maintained a policy of not extending the library with extra
features. However, this seems like the way forward to me and all the
new features that convert has can be added to lexical_cast. Some have
even been added and proposed as patches, but they weren't accepted due
to this aforementioned policy. Now that this is no longer a problem I
believe we should be extending lexical_cast instead of adding another
library, especially since deprecating lexical_cast is not an option.

I'm working on a library which is taking the spirit road you
mentioned; it's called coerce and can be found in the boost sandbox.
It still has some rough edges but I've proposed a GSoC project to fix
this, see http://boost.2283326.n4.nabble.com/GSoC-coerce-previously-construe-cast-td3425166.html.
This I believe to be a completely different approach whilst the
convert library seems to be reimplementing lexical_cast instead of
fixing it.

Regards,
Jeroen