Optional: C++0x features

[jgottman@…]

There are a couple of features in C++0x that would be very useful in the optional library. First is the emplace function (see ​http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2345.pdf). This is how the C++0x containers will do in-place construction; optional should allow it as well so the same operation can be done in the same way. One issue is what to do if we call emplace on an optional that is not empty. We could assert, throw an exception, reset and then construct in-place, or construct out-of-place and then swap. Personally I prefer the third option.

Second, optional should make use of rvalue-references where available. Note that if swap() were implemented using the move constructor and move assignment operator, then it would just do the right thing with respect to iterators to the standard containers.

template<class T>
inline
void optional_swap ( optional<T>& x, optional<T>& y )
{
  if ( !x && !!y )
  {
    x.reset(std::move(*y));
    y.reset();
  }
  else if ( !!x && !y )
  {
    y.reset(std::move(*x));
    x.reset();
  }
  else if ( !!x && !!y )
  {
// GCC > 3.2 and all other compilers have the using declaration at function scope (FLC)
#ifndef BOOST_OPTIONAL_STD_SWAP_INTRODUCED_AT_NS_SCOPE
    // allow for Koenig lookup
    using std::swap ;
#endif
    swap(*x,*y);
  }
}

[mlcreech@…]

Are there any plans to add support for rvalue references to boost::optional? This makes a very big difference on C++0x code.

Also, bug severity should not be "optimization" - as things are, classes which are movable but not copyable can't be used at all with boost::optional (compile errors), whereas if move semantics were respected it would work fine.

[mlcreech@…]

Partial move support

[mlcreech@…]

I've attached an example patch which fixes my build problems when using boost::optional with noncopyable objects. It doesn't handle move semantics for boost::optional objects themselves, but does for the underlying type.

[NN]

I support this patch. C++0x move feature makes code much better optimized !

[Fernando Cacciola]

I will be working on adding this next week or the one after.

Best

[boost@…]

Hi, I stumbled across this ticket while looking for a solution for the same issues with move-only types in Boost.Optional, will there be a fix anytime near in the future?

Regards, Arne

[mlcreech@…]

Arne, does this patch work for you? It at least fixed the build problems I was having. I'm still using it with 1.48, I'll post an updated version.

I'm going to change the type/severity also: this problem prevents code from building which should otherwise work when move semantics are enabled.

[mlcreech@…]

Updated patch for 1.48

[Fernando Cacciola]

I started work on this

[jmckesson@…]

Is this going to be implemented anytime soon?

[tjackson@…]

I'd love to see this completed. Any updates?

[zeratul976@…]

+1, I'd like to see this as well!

[Fernando Cacciola]

I (re)-started working on it this week.

[Mozza314]

+1 Surely this is a no-brainer. optional should take advantage of move semantics.

[Lindley]

This still appears to be unfixed in 1.54. This needs to get done.

As it stands now, this bug prevents the Signals2 library from being used with a move-only return value from a slot such as a std::future, among other things.

[akrzemi1]

move semantics, improved swap and function emplace() added in branch master.