From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2002-07-25 05:10:55
Eric Friedman wrote:
> So in the same way, I see the following runtime code (example 1):
> if (condition) f(); else g(); // 1.1
> as analogous to:
> mpl::apply_if<condition, f, g>::type // 1.2
> While I see the following runtime code (example 2):
> condition ? x : y; // 2.1
> as analogous to (and here is my point):
> mpl::if_<condition, x, y>::type // 2.2
> As David Abrahams points out, this trailing-underscore type-naming
> convention is to allow a keyword-like name to be used in a
> user-defined context. Yet while 2.2 employs a type named in this
> convention (i.e. if_), 2.1 does not have the if keyword in sight.
> Meanwhile, 1.1 *does* employ the if keyword, suggesting that in
> fact 2.2 is analogous to 1.1 (which is very far from true).
> For these reasons, I think the mpl::if_ name may be an
> unnecessary point of confusion for new users of MPL and restate
> my proposal that the mpl::select_if name be restored.
Funny you should mention that - I thought that 'if_' would be _easier_ to
grasp for novices who usually don't analyze things so thoroughly as you did
in the above paragraph :).
In any case, I happened to think that accurate analogy with the run-time
world is not a necessary condition for a name to be easily understood and
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk