Boost logo

Boost :

From: David B. Held (dheld_at_[hidden])
Date: 2003-10-09 06:31:48

"David Abrahams" <dave_at_[hidden]> wrote in message
> "Joel de Guzman" <joel_at_[hidden]> writes:
> > [...]
> > struct square
> > {
> > template <class X>
> > struct sig { typedef X type; }
> > X operator()(X x) { return x * x; }
> > };

I don't understand this example. Is operator() also supposed to
be templated? If so, what connects sig<> with operator()?

> [...]
> b. It should be called apply, because that just makes it
> cheaper and easier to use: instead of
> [...]

But my understanding is that apply<> is the compile-time way
to spell "operator()" for function objects. If sig<> is really
the definition of R for "R operator()", without being the result
of operator(), should it really be spelled "apply<>"? It seems
to me that there is a confusion between runtime and compile
time here. The fact that apply<> works syntactically adds to
the confusion.

In Joel's example above, square could be a metafunction
object as well as a function object. But what kind of
metafunction is it? It's the identity metafunction. Clearly,
this is different from it's name and run-time purpose. That's
because sig<> does not reflect it's intent, only its return
value to support lazy evaluation.

So in this case, I think calling the return type metafunction
"apply<>" is confusing, even though it makes it convenient
to use with MPL::lambda. I think I agree with Joel that it
should be called result<>. Even though it *could* be used
with lambda, how would you do so? The result of apply<>
is not square, as one would hope, but X. What are you
going to do with the return type by itself?

There definitely needs to be a convention. And maybe
ReturnTypeMetafunction needs to be a formal concept
that encapsulates that convention and specifies a name.
But I don't think the name should be "apply<>".


Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (
Version: 6.0.521 / Virus Database: 319 - Release Date: 9/23/2003

Boost list run by bdawes at, gregod at, cpdaniel at, john at