On 3/2/2014 4:49 PM, Vladimir Batov wrote:
On 02/21/2014 08:31 AM, Edward Diener wrote:
On 2/16/2014 3:56 PM, Vladimir Batov wrote:
Addressed all three comments... I think. Checked in. ... This looks good. I think you have successfully focused on what is needed for a more flexible lexical_cast-like version this time. ...
I think I've addressed all comments/suggestions received so far and I feel quite good about the current state of the documentation. In particular I've extended the number of available/tested converters (based on lexical_cast, strtol, sprintf, sstreams) and reflected that in the Performance section.
The new location is at https://github.com/yet-another-user/boost.convert.git
What puzzles/disappoints me is this. lexical_cast has been around for quite some time and with its potential standardization I presume quite a bit of optimization effort went into it (I personally cannot understand the code). On the other hand the "convert" code is dead simple with no thoughts given to optimization. Still, "convert" easily "beats" lexical_cast :-( on both "fronts" -- for basic conversions like string-to-int and user-type conversions.
I applied all the tricks that Rob and Alex suggested regarding performance tests to level out the playing field. Still, could that be that lexical_cast is somehow disadvantaged in my tests?..
With "convert" I can plug easily different converters into the framework when lexical_cast by comparison looks quite rigid. So, for basic string-to-int boost::convert with the strtol converter gives me twice the performance of lexical_cast. For complex user-type conversions I plug sstream-based converter and again get twice the performance of lexical_cast with the bonus of formatting and locale, etc. What would be the domain where I might perfer lexical_cast? Not trying to insult anyone. Only looking for answers.
Any additional input is most welcomed.
The lexical_cast functionality/syntax is a straightforward implementation of the standard conversions between strings and basic types without having to specify istringstream and ostringstream. Its simplicity probably explains its popularity as well as anything. I would guess that the vast majority of C++ programmers don't worry about speed of execution very much. Similarly istringstream and ostringstream were improvements over C functionality, integrating string back and forth conversions into the C++ iostreams. If you feel that your library is an improvement over lexical_cast I see no reason why it cannot be considered as a Boost library pending a review. Sometimes small steps are much better than large leaps. As far as speed of execution a good profiler would probably tell you where lexical_cast would be slower or faster when it executes just as you could discover that for your own library. Perhaps then you would discover why your library executes faster in your tests.