Fernando Cacciola wrote: > OK, I can see the motivation: We can have a noncopyable class > and need an optional object of it. > Following optional semantics, it would be spelled: > > boost::optional<RAII_lock> lock; > if ( cond ) > lock.reset( RAII_lock(entity) ) ; > > But there is a probem: as William pointed out, reset() _needs_ > to use T::T(T const&) in order acquire its own copy of the object; > but in this case is noncopyable, so the above won't compile.
Yep. [...] > > * Secondly, you would need a templated constructor to allow T to be > > constructed using another type. > > > Exactly. > One possibility would be add additional templated ctor and reset > that just forward the arguments to T's contructor (optional's interface > could use a trailing tag to differentiate these). > > A problem with this is that the Argument Forwarding problem is burried > into optional's itself. I think it's more of a language problem than anything else. I mean, there is nothing conceptually wrong with allowing 'optional' to support something like 'opt.construct(a1,...,an)', IMO; only implementation ugliness. > Another approach would be to create a generic delay-factory > object and just let optional use it: > > Something like: > > template<class T, class A0> > struct in_place_factory0 > { > in_place_factory0 ( A0& a0_ ) : a0(a0_) {} > > T* operator() ( void* address ) const { return new > (address) T(a0) ; } > > A0& a0 ; > } ; > > template<class T, class A0> > in_place_factory0<T,A0> in_place ( A0& a0 ) { return > in_place_factory0<T,A0>(a0) ; } > > which requires the following changes in optional<>: > > template<class T> > class optional > { > public : > > .... > > template<class Factory> > explicit optional ( Factory f ) > : > m_initialized(false) > { > construct_inplace(f); > } > > ... > > private : > > template<class Factory> > void construct_inplace ( Factory f ) > { > f(m_storage.address()); > m_initialized = true ; > } > } ; > > The above would allow something like this: > > optional<RAII_lock> l( in_place<RAII_lock>(entity) ); > > If the same in-place idiom is used on reset(), the complete > solution will look, following optional<>'s way: > > boost::optional<RAII_lock> lock; > if ( cond ) > lock.reset( in_place(entity) ); > > What do you think? Well, it's a little too verbose and un-idiomatic than I would hope for. May be my original desire to re-use 'optional' in this context was ill-conceived, and what I really need is a separate 'optional_lock' class - which, although definitely similar, will be significantly simpler than 'optional' itself. Although boost::optional<scoped_lock> lock(cond, entity); definitely seemed so intuitive and close. Aleksey _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost