Got 3 sisters fighting in mind: (function pointer, function object, lambda function)

Hi Experts,

I got 3 sister concepts playing and colliding in my mind. I know each can be passed to another function. All of them seem to me like alternatives with subtle differences.

1. function pointer: a pointer to a function

2. function object: instance of a class that has overloaded the () operator; capable of acting as a function;

3. lambda function: an anonymous function (newly introduced in C++11) that may be defined on the spot and that exists only during the lifetime of the statement of which it is a part

Because of the subtilities, I wonder which of the 3 choices would be the most appropriate in a given scenario. So, experts out there, kindly shed some light (on some selection criteria?) so that I could decide and use them in different scenarios.

BR,
softwarelover

They all have their uses.
1. if you interface to code that is not C++.

2 and 3 are basically equivalent ways to achieve the same. lambda's are syntactic candy that result in function objects. This assumes templates.

You forgot 4.
and that is passing a regular object that has virtual functions.

Depending on the needs, there may be additional means to achieve what you want such as events, messaging, ...

Quote:

---

Originally Posted by softwarelover

3. lambda function: an anonymous function (newly introduced in C++11)

---

no, they are not anonymous functions; lambdas ( technically, the result of the evaluation of a lambda expression, called the closure object ) are unnamed function objects defined by the compiler. Lambda expressions are just a convenient syntax to define simple copy/move-constructible function objects with an inlined operator(). Moreover, lambdas without capture are implicitly convertible to a function pointer with the same signature; hence, lambdas can be used whenever a function object or a function pointer is used.

regarding the "sisters", I'd drop the lambdas ( being just syntax ) and I'd add:

3. member function pointers: these are similar to function pointers, the main difference being that they need an object instance in order to be invoked ( eventually polymorphically; note that there are also other technical differences with respect to function pointers, especially considering their implementation on most compilers ... ).
4. polymorphic function objects: std::function<F>. These are function objects wrapping a callable invoked polymorphically.

Quote:

---

Originally Posted by softwarelover

3. lambda function: [...] that may be defined on the spot and that exists only during the lifetime of the statement of which it is a part

---

this is not true, in general; the closure type (that is, the type of the lambda) is declared in the enclosing scope and the closure object behaves exactly as a temporary of closure type, which means that it could also survive the full expression in which it appears. Moreover, copies/moves of the closure object can obviously live indefinitely.

Quote:

---

Originally Posted by softwarelover

I wonder which of the 3 choices would be the most appropriate in a given scenario

---

well, from the function writer POV, if you support one you often support the others ( unless you're writing a C-library, of course ), which means just (member)function pointers and function objects, often with the aid of templates.

From the user POV, you use function objects when you need to equip the "callable" with state or some extended semantics ( members, member types, etc... ); take also a look here. Regarding polymorphic function objects, you use them when you need an opaque collection of function objects, sharing the same signature; they are a generalization of function pointers.

wow wow. thanks all.

superbonzo,

Isn't anonymous synonymous with "unnamed"? [thinking about the anonymous class concept in Java]

Quote:

---

Originally Posted by softwarelover

Isn't anonymous synonymous with "unnamed"? [thinking about the anonymous class concept in Java]

---

yes, it is. I was just pointing out that lambdas are not "functions"; they are expressions resulting in "ordinary" function objects.

Quote:

---

Originally Posted by softwarelover

Because of the subtilities, I wonder which of the 3 choices would be the most appropriate in a given scenario.

---

In fact the new C++ 11 standard helps with this decision. In 5.1.2 Lambda expressions,

"Lambda expressions provide a concise way to create simple function objects."

So whenever you want to create a simple function object prefer a lambda expression. It makes sense to use the highest abstraction level a language has to offer therefore try a lambda expression before any other alternative.

That aside the big question now instead becomes, why have the designers of the C++ language suddenly decided to make it much easier to use function objects? Do they offer an advantage I'm maybe not aware of? Should I use them more frequently then I currently do? Should I even change my design style because of them? Those are 64.000 dollar questions to ponder carefully.

I'm a great believer in syntactic sugar. The sweeter the better. The more easily and elegantly you can make use of powerful concepts the better the syntax. To me lambda expressions are syntactic sugar of the third kind. It has the power to expand people's mindsets about programming. And C++ even beat Java to it.

---

Thanks nuzzle. One interesting term is "syntactic sugar" which by now I have come across a couple of times.

Quote:

---

Originally Posted by softwarelover

One interesting term is "syntactic sugar"

---

I don't quite like this term because what's syntax and what's syntactic sugar in a language? The division is very artificial and rather meaningless. And also it has a slightly condescending ring to it. Like that some constructs would be "mere" syntactic sugar that has been added only to sweeten the deal for lesser programmers who otherwise would have a hard time doing what real programmers have been doing anyway all the time.

But the other posters used it and I wanted to balance that. What I mean really is that I find lambda expressions to be a great extension of the C++ language. I think you always should try them before function pointers and function objects. And I also think you should seek to expand your use of lambda expressions using them in more situations and more frequently.

Quote:

---

Originally Posted by nuzzle

I don't quite like this term because what's syntax and what's syntactic sugar in a language? The division is very artificial and rather meaningless. And also it has a slightly condescending ring to it. Like that some constructs would be "mere" syntactic sugar that has been added only to sweeten the deal for lesser programmers who otherwise would have a hard time doing what real programmers have been doing anyway all the time.

---

paranoia ? :) the OP listed some "callables" focusing on their differences with respect to function passing as callbacks. Lambdas, being expressions generating function objects, should not appear in that list and that's it. There's no "subtle difference" between a function object and a closure object, hence in this ( and only in this ) sense they're "just" syntax ( that, BTW, is a very good thing because 1) you don't have to learn a new set of rules governing the behaviour of yet a new type of callable and consequently 2) they automatically work with libraries designed for function pointers/objects ).