Re: [boost] [multiindex] internal scope_guard has changed access from public to protected

Subject: Re: [boost] [multiindex] internal scope_guard has changed access from public to protected
From: Jeffrey Lee Hellrung, Jr. (jhellrung_at_[hidden])
Date: 2010-05-29 18:14:32

On 5/29/2010 2:31 PM, Thorsten Ottosen wrote:
> Jeffrey Lee Hellrung, Jr. skrev:
>
>> However, it appears Thorsten's implementation creates a null_guard if
>> the condition *is* true (the boolean is named "is_null", after all).
>> I'd consider Joaquin's semantics to be less confusing.
>
> Oh, I overlooked that. I simple did what felt most natural
> from a usage perspective, to avoid negating the constant. AFAICT, this
> the most common usage scenario. Thus when I see
>
> make_guard_if<boost::has_nothrow_copy<T>::value>( ... )
>
> I don't read the _if alone (as part of what is being returned), but I
> read the whole make_guard_if<> as a tool that generates guards as needed
> depending on has_nothrow_copy<>.
>
> Joaquin, what is your take on this?

Certainly, if one sees

do_something_if< cond >( ... )

you can sympathize with one reading this as "if cond, do something" ;) 
Consider those who may not be intimately familiar with make_guard_if but 
stumble upon such a construct in reviewing code.  I think I, for one, 
would be confused.

But the choice of semantics is ultimately up to you and Joaquin.

>> Also, since I'm here, perhaps you should have a make_obj_guard_if_c
>> taking the boolean template parameter, while make_obj_guard_if takes a
>> Boost.MPL boolean constant class. This is the convention used by
>> Boost.EnableIf and Boost.MPL (among other Boost libraries), right?
>
> The if_c<> code is usually pure meta code which is not the case here.
>
> -Thorsten

There is precedent in Boost.Fusion, e.g., at_c and advance_c.

- Jeff