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.
There is precedent in Boost.Fusion, e.g., at_c and advance_c.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk