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-09 14:45:40

On 8 April 2011 01:52, Vladimir Batov <vbatov_at_[hidden]> wrote:
>> ----- Original Message ----- From: "Jeroen Habraken" <vexocide_at_[hidden]>
>> ...
>> ... 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.
>
> If the situation with regard to lexical_cast has changed so dramatically,
> then I am certainly not aware of it. Would you mind elaborating how you've
> come to the conclusion that lexical_cast is now open for improvements? By
> "improvements" I mean chiefly interface extensions as without fallback
> value, configurable throwing behavior, locale, formatting, etc. lexical_cast
> has very limited application.

Since the library is without a maintainer I believe if someone steps
up it can be taken forward. The features you mention would certainly
be nice to have.

>> 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.
>
> Here we need to separate and constantly keep in mind the fact that there are
> always two sides to every coin. In case of development they are interface
> and implementation. If one needs to manage resources and to minimize the
> effort to achieve certain result (rather than simply enjoying the process of
> writing code), then interface and implementation need to be addressed
> separately and interface has to come first. With interface worked out and
> *some* implementation one can ship the product and start gathering feedback
> while improving underlying implementation (say, performance-wise).
>
> That's the road I've taken with Convert. The major effort so far went in to
> Convert interface. Consequently, I have to disagree that "convert library
> seems to be reimplementing lexical_cast". I am well out of my rebel years
> when I simply wanted to reimplement something existing just because the
> "new" one would be "mine" and a notch faster. Convert provides considerably
> richer interface (IMHO of course) and that considerably widens Convert
> applicability compared to lexical_cast. Granted, currently under-the-hood
> Convert still uses stream-based engine for some conversions. However, it was
> not a result of underlying design but a pragmatic decision to start testing
> the concept quicker. Does it perform its best performance-wise? Hardly.
> However, it rolls the product out to the potential users (now I seem to
> sound like a manager ;-) ) many of which mind you are not so
> performance-minded. Now I'd be very happy for you to step in and to apply
> your "completely different approach" to the implementation within the
> boundaries of the agreed interface. Here I am in agreement with Hartmut
> Kaiser and others that Spirit would be a worthy conversion engine (where
> applicable). Can you propose/incorporate your work for/into Convert? I am
> not saying Convert is better than what you've done so far. What I am saying
> is that together we'll achieve more and logistically Convert just happens to
> be further along that acceptance road. If you want, you can have all the
> kudos and laurels and whatever... I did not want to write that Convert in
> the first place anyway... I was hoping someone else would extend
> lexical_cast to make it useful/usable *for* me ;-)
>
> So, what do you say?

Your library does have richer interface but will inevitable implement
parts that are already in lexical_cast when sticking to the
stream-based implementation. I consider this undesirable since it is
unlikely that lexical_cast will be deprecated once your library is
added.

Considering the merging of the two libraries, I believe it to be a bad
idea. This is only useful if both implementation return exactly the
same results for each function which, considering locale etc., is
simply impossible. If you wish to only have a spirit based
implementation it makes no sense to incorporate my code into convert
either.

> V.

Jeroen