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: Vladimir Batov (vbatov_at_[hidden])
Date: 2011-04-07 19:52:07

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

> 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?

V.