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.