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