Boost logo

Boost :

Subject: Re: [boost] [review] Convert library
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2014-05-26 04:28:42


2014-05-25 16:37 GMT+02:00 Hartmut Kaiser <hartmut.kaiser_at_[hidden]>:

>
> > > Note that for this to be efficient I'd like to see the optional to be
> > > movable, which isn't yet the case with boost::optional if I'm not
> > > mistaken.
> >
> > You might have noticed that I mention std::tr2::optional... which has
> what
> > you are after. Andrzej is working on incorporating/backporting those
> > features to boost::optional. "Life happened" to him also :-) but I am
> > hoping, if we are extra nice, he might just might to get the interface we
> > are after into 1.56. Andrzej, ple-e-e-ease, pretty pretty please!?
>
> Honestly, when I first realized your convert() returns an optional I felt
> something like revulsion. This is for two reasons:
>
> a) While an optional exposes an operator*() and an operator->(), the
> resulting conversion syntax turns into something more complex than it has
> to
> be.
> b) Using optional means you need an additional allocation (at least
> sometimes if you have an improved version using small object optimization
> internally). I tend to say that this alone can turn into a knockout
> criteria
> for a supposedly high performance, low level conversion library. However I
> have not done any measurements - so all this is pure conjecture.
>

I just wanted to clarify one detail about the implementation of
boost::optional. By design, it does not allocate heap memory for any type
T, however big. It uses an internal aligned_storage-like facility to store
the object. This aside, your point about performance may still be valid for
other reasons (like returning by value an object bigger than necessary). I
do not have a measurable evidence either.

Regards,
&rzej


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