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: Joaquin M Lopez Munoz (joaquin_at_[hidden])
Date: 2010-05-30 05:39:17

Thorsten Ottosen <thorsten.ottosen <at> dezide.com> writes:

> 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?

I concur with Jeff's poins of view in both respects:

* make_guard_if<cond> should construct the guard if cond is true
(I overlooked the fact that your implementation does the opposite, sorry).
I think this is the obvious semantics for anyone reading the construct:
make a guard if so and so.
* It'd be nice if we have both the following:

  template<typename IsNull, ...>
  inline typename null_guard_return<..>::type
  make_guard_if(...)

  template<bool is_null, ...>
  inline typename null_guard_return<..>::type
  make_guard_if_c(...)

just like enable_if and enable_if_c, which is probably the closest
existing practive we've got in Boost.

As for make_guard_unless (and make_guard_unless_c) I guess it's
up to you to provide it also, at the risk of being a little
overabundant at providing variations on the same basic theme.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo