2014-05-25 16:37 GMT+02:00 Hartmut Kaiser
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