Boost logo

Boost :

Subject: Re: [boost] [review] Convert library
From: Jeroen Habraken (vexocide_at_[hidden])
Date: 2014-05-26 04:33:45


On 26 May 2014 10:12, Vladimir Batov <vb.mail.247_at_[hidden]> wrote:

> Joel de Guzman wrote
> > On 5/25/14, 6:34 PM, Jeroen Habraken wrote:
> > > ...
> > > [4] http://www.kumobius.com/2013/08/c-string-to-int/
> >
> > This makes me wonder. How fast is Convert BTW? How does it compare
> > to the examples in that benchmark? Boost is performance hungry! It
> > will be a real cause of concern if it is slower than the benchmarks.
>
> "convert" has no benchmarks of it own... because it does nothing. :-) It's
> a
> "manager" class rather than a "worker" class. It's merely an interface to
> coordinate/unify and uniformly deploy (or quickly swap on when-needed
> basis)
> varying conversion facilities. So, with the "coerce"-based converter
> "convert" performs as fast as "coerce". I actually ran tests with
> lexical_cast and others: naked lex_cast vs. convert+lex_cast. No
> performance
> degradation. I mention it in the docs.
>

This will unfortunately not be the case if Hartmut is right, and Andrzej
just confirmed he might be. The optional-based interface may actually
introduce more in overhead than boost::coerce requires for the conversion.

As said this needs to be backed by numbers, which is difficult without the
std::tr2::optional in boost, but this may turn out to be a problem to me.
Later versions of GCC are actually capable of optimizing

    boost::coerce::as<int>("23");

to the number 23 at compile time. I'd be a shame to have this obstructed by
an optional.

Jeroen


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk