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