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
