From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-07-25 08:35:47
From: "Eric Friedman" <ebf_at_[hidden]>
> "Peter Dimov" <pdimov_at_[hidden]> wrote:
> > From: "Eric Friedman" <ebf_at_[hidden]>
> > > The following excerpt is from a private conversation with Aleksey:
> > >
> > > > > [Eric]
> > > > > Any possibility that if_ will return in name to select_if? I find
> > > > > select_if to be a superior name for the following reasons:
> > > > >
> > > > > if_ is visually distracting; OTOH select_if is visually-similar
> > >
> > > > > apply_if.
> > > > > if_ is a bad analogy to runtime C++. In runtime C++ the if
> > >
> > > > > invokes code, ?: operator selects a value.
> > In compile time C++, nothing invokes code, and everything selects a
> > It's a pure functional language.
> That's why I used the word "analogy". Most of MPL is based upon analogiy
> runtime C++; for example, even though as you say "nothing invokes code",
> mpl::apply is an analogy to function invocation. That is, mpl::apply<f, x,
> y>::type recalls f(x,y); in my mind -- which I do not believe is
> 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
No, the analogy is flawed. In a pure functional language, 1.1 is a no-op,
since f() and g() aren't allowed to have side effects... this is what I
meant by "invokes code." It has no equivalent.
condition? f(): g()
or (in a statement form)
if(condition) return f(); else return g();
are analogous to 1.2.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk