Boost logo

Boost :

Subject: Re: [boost] [multiindex] internal scope_guard has changed access from public to protected
From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2010-05-27 06:47:14


Thorsten Ottosen skrev:
> Hi Joaquin,
>
> Sorry for the slow response.
>
> Joaquin M Lopez Munoz skrev:
>> Thorsten Ottosen <nesotto <at> cs.aau.dk> writes:
>>
>>> Joaquin M Lopez Munoz skrev:
>>>> Yep, why can't you just define null guard as
>>>>
>>>> struct null_guard:boost::multi_index::detail::scope_guard_impl_base{};
>>> the ?: operator seem to require that the second argument can be
>>> converted to the type of the first argument.
>>
>> I might be missing something, but I think tou can simply
>> write the following to circumvent the problem:
>>
>> #define BOOST_AUTO_BUFFER_CONSTRUCTOR_SCOPE_GUARD() \
>> boost::has_nothrow_copy<T>::value ? \
>> static_cast<boost::multi_index::detail::scope_guard>( \
>> boost::auto_buffer_detail::null_guard()) : \
>> static_cast<boost::multi_index::detail::scope_guard>( \
>> boost::multi_index::detail::make_obj_guard( \
>> *this, \
>> &auto_buffer::deallocate, \
>> buffer_, members_.capacity_ ))
>>
>> Does this work?
>
> It seems to work.

I take that back. operator ?: seems to generate a redundant copy which
kills this approach.

>> Additionally, why are you doing the
>> guard selection on run time? boost::has_nothrow_copy<T>::value
>> is a compile-time value so you can select the exact
>> type of the guard (null or otherwise) with some Boost.MPL.
>
> Well, I'm lazy, so I didn't want to implement the functionality twice
> with and without the guard. IMO the code is very clear with this macro.
> I think the optimizer has no problem removing the empty guard.

It seems to me that creating a null-guard conditioned on some
compile-time value is quite common in containers that copy elements
around.

Would it not be possible to add a bool template parameter to
make_obj_guard() such we can simply write

  scope_guard g = make_obj_guard<some_condition<T>::value>(...);

?

-Thorsten


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