C++ Lambdas - OOP violation ?

I have adopted to the use of lambdas in the meantime, but i would like to start a little discussion about the ever escalating use of lambdas and the motivation to do so.
Typical justifications to use lambdas include statements like "relieve your classes from too much methods", "your code gets more readable" or "you need not scroll around to see the declaration of a member function". The last one i consider completely irrelevant - simply use a decent IDE like Visual Studio, where you can temporary blend in the definition in place, for example.
Better readable ? I doubt it. The main thing i appreciate personally is the possibility to return lambdas from a function/method as a return value.

To me, lambdas have been mainly introduced to address younger programmers or developers who switch from a more "modern" language to C++ for some reason.

I am aware that a lambda is not exactly an anonymous or inline function, but it behaves like one. So there i indeed see the danger of code proliferation, like it is a sorry habit in C#.

But the first one - "relieve your classes from too much methods" - in my opinion clearly is an attempt to violate the principles of object-oriented design/programming.
If additionally the use of structures instead of classes becomes more and more common, it gets a smack of trying to raise C over (object oriented) C++ which is retorting me. C is nothing but the lesser part of C++.

What do you think ?
Last edited on
in my opinion clearly is an attempt to violate the principles of orient-objected design/programming.


Putting aside whether or not lambdas are some kind of violations, when those principles lead to an overall worse outcome, they should be violated.

If additionally the use of structures instead of classes becomes more and more common,

In C++, a struct and a class are identical except for default access and inheritance. I could replace every class in my code with a struct, check I've made the right things private, and get identical results.
Last edited on
Please justify that, then.
object-oriented, of course. Seems i mistyped it.
Given two options

1) Obey OOP principles
2) Do not obey OOP principles

if option 2 leads to an overall better outcome, we should choose that one.

You want me to justify this?
Last edited on
Hi bieblsoft,
I don't know the roadmap nor the big plan of the standard commity. Maybe they have some real answer to you.

To me, a lambda is an important semantic element and C++ didn't have that element until now.
Readibility doesn't really mean "easy to read" (we know that now with C++) nor does it mean "simple to read".
But lambda emphazises something important to me : put the definition of the thing needed the very next to where it is needed.

For example, this is horrible like aaaaaaaaaaaaahhhhhhhhhhhhhhh /o\ :
1
2
3
4
5
6
7
8
9
10
11
void f()
{
	int const pi = 3;
	std::string const pikachu = "goku";
	// and some zillion definitions like that
	...
	// then here, use pi
	... // a billion line afterwards
	// use pikachu variable
	// etc.
}


It's so much better, even if that doesn't change anything at all, to have :
1
2
3
4
5
6
7
8
9
10
void f()
{
	// a million line of code here
	int const pi = 3;
	// use pi now
	// a billion line of code
	std::string const pikachu = "goku";
	// use pikachu here...
etc.
}


Lambda are the same... you define your very function where you need it.

But you've got a good point... there is no real reason why we needed lambdas in C++.
But having a kind of "function object", not only a pointer to a function, is a real advance concept. It's just like reference and pointers... what the hell ?

Well, in turns out that with that little bit of semantic (the reference), you can then create the definition of operator ^_^. Only with pointers, this is not possible because of the semantic the pointers have with the additionnal "*" and "&".

And finally, with lambdas, we enter the realm of lambda calculus... to violate the rules right from the beginning, ok, but we now have a step in it \o/
Typical justifications to use lambdas include statements like
These statements doesn't make sense since lambda is not a function and can only very limited be used as such. It cannot be a member function or whatever you have in mind with this statements. lambdas are certainly not meant to be used as global unnamed functions.

lambdas is supposed to be used within a function. They are usefull when another function requires a function object and you want to use local variables of the current function. Without lambdas you need to make the local variables member variables or worse.

So lambda is not a real function but a wrapper for a function to use local variables in the context of another function. If a real c function pointer is required you cannot use all features of lambda (those features which deviates from a real function).

OOP is an object/variable centric point of view. I cannot see where lambda violats this.
@repeater:
of course. This was intended to be a discussion. As such, if you make bold statements like these, you surely need to justify them.
It seems that we need to look at the definition of lambdas. Here's the one Microsoft makes:
"In C++11, a lambda expression—often called a lambda—is a convenient way of defining an anonymous function object right at the location where it is invoked or passed as an argument to a function. Typically lambdas are used to encapsulate a few lines of code that are passed to algorithms or asynchronous methods."

@coder777:
A Lambda is of course not a class or object method, as such, it would have to be adressable as a part of the class / object. This is exactly what a lambda cannot be.
It is not a global function as well, because of the same.

But a lambda can be called like a function, passing parameters, returning values or even other lambdas. Lambda statement or lambda expression is essentially the same thing, if you don't care how many statements it includes - and there is no real reason to do so.

@ punksheep:
Lambdas are not essentially an important semantic statement in C++ - i have used C++ alright since over 30 Years now without them and there is no almighty international normation commitee defining the rules a programming language has to implement. If you yourself consider it necessary, that is ok for you.

@coder777:
OOP is an object/variable centric point of view. I cannot see where lambda violats this.

If you implement, for example, a sorting container as a class, the sorting method would be a method of this class. To do without this and instead doing the sort with a Lambda in the place where you want the sorting to happen, is what i consider such a violation.

Besides that: I am very glad to see that there are people really interested in the topic. Thank you for your replies and Participation !

of course. This was intended to be a discussion. As such, if you make bold statements like these, you surely need to justify them.


Okey dokey. By definition, a better outcome is preferable to a worse outcome, and from this we can see that given a choice of a better outcome or a worse outcome, the better outcome is better.

there is no almighty international normation commitee defining the rules a programming language has to implement.

There is the C++ committee. They do that for C++.

What is the problem with doing something in a non-OOP way? OOP isn't magic and it isn't religion.
Last edited on
bieblsoft wrote:
Typical justifications to use lambdas include statements like "relieve your classes from too much methods",

That's the justification for ordinary, namespace-level functions. The ideal C++ class interface consists of non-member functions defined in the same namespace as the class, implemented in terms of the irreducible set of public member functions, and the virtual member functions (if any) are non-public. Lambdas don't feature anywhere here.

bieblsoft wrote:
If you implement, for example, a sorting container as a class, the sorting method would be a method of this class.

No. Only std::list and std::forward_list have member sorts, and that is questionable 1992 design that didn't carry over into ranges.

bieblsoft wrote:
To me, lambdas have been mainly introduced to address younger programmers or developers who switch from a more "modern" language to C++ for some reason.

C++ language development is a matter of public record: you can look up exactly why they were introduced in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1958.pdf and http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1968.pdf

To summarize, the two main reasons were:
1. To standardize widespread existing practice (I can attest to that, I was using lambdas in C++ since 2005, those libraries were around since at least 2001),
n1958 wrote:
closures are one of the most important missing C++ features, and there were many well known attempts to solve this problem on the library level
2. To make it easier to create function objects:
n1958 wrote:
many generic programming patterns will not enter the mainstream until C++ supports a simple and efficient way to construct such function objects inline
and
n1968 wrote:
The lack of a syntactically light-weight way to define simple function objects is a hindrance to the effective use of several generic algorithms in the Standard Library.
Last edited on
Topic archived. No new replies allowed.