Re: [boost] Convert. Take 2.

Subject: Re: [boost] Convert. Take 2.
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-03-02 21:54:28

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.