On 8 April 2011 01:52, Vladimir Batov <vbatov@people.net.au> wrote:
----- Original Message ----- From: "Jeroen Habraken" <vexocide@gmail.com> ... ... 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-td34.... 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