Hi, On 7 April 2011 11:19, Vladimir Batov <vbatov@people.net.au> wrote:
----- Original Message ----- From: "Vicente BOTET" <vicente.botet@wanadoo.fr>
... 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-td34.... 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