4 ms·

> You may even have to inherit a base class or implement an interface. Subtype polymorphism is a very poor substitute for closures. This is why C++ algorithm li

by pbsd 13y ago

> You may even have to inherit a base class or implement an interface. Subtype polymorphism is a very poor substitute for closures. This is why C++ algorithm library is unusable. Does anybody understand what the author means by this? STL's algorithm library does not use class hierarchies for anything. And they often take functions (be they free functions, lambdas, or functors) as arguments.

nly 13y ago
The author probably had (this was written 3 years ago) a bitter and rather narrow view of OOP capable languages. In C++ a class is just a facility of the language with many different features. If you want immutable, value-semantic objects, then do it. If you want a closure... well objects can be closures too. C++ calls them functors, they can be immutable. In fact, C++11 lambdas are immutable by default. His criticism of the STL is probably that they expose their mutation, rather than hiding it in the architecture like pure functional languages. In C++ you just have to hide the infrastructure yourself.
- humanrebar 13y ago
  The overhead that is assumed unimportant by most functional languages (copying is cheap, GC is fine, etc.) is intolerable in key situations and problem domains. In C++ all overhead must be optional. That being said, nearly all C++ applications can benefit from immutable classes, algorithms that take closures, and so on. But C++, like C before it, is really just an abstraction of the hardware and OS below it. That hardware mutates. That pool of memory changes size and locality. The closer your problem domain is to the metal (especially drivers and highly-optimized code), the more you appreciate mutable state, at least given the current state of computing.
  - pkolaczk 13y ago
    Dealing with complex immutable data structures without GC is either extremely hard or inefficient (and usually both). C++ standard library does not offer any helping hand here either. Additionally C++ logical memory model (flat, uniform memory) does not describe the hardware memory model well - it is already an abstraction. An memory access isn't uniform and mutations can cost you really very much. In some cases immutable structures + little copying is often the way to go, especially when we aim at parallelization.
deleted 13y ago
[deleted]
blt 13y ago
Before C++11, if you wanted to pass a function with closure-like behavior to an STL algorithm, you had to write a little class with operator() overloaded. It was a huge pain in the ass, lots of boilerplate code. Most programmers didn't bother and wrote plain loops. Now with C++11 lambdas, std::algorithm is much nicer to use.

by pbsd 13y ago

nly 13y ago

The author probably had (this was written 3 years ago) a bitter and rather narrow view of OOP capable languages. In C++ a class is just a facility of the language with many different features. If you want immutable, value-semantic objects, then do it. If you want a closure... well objects can be closures too. C++ calls them functors, they can be immutable. In fact, C++11 lambdas are immutable by default. His criticism of the STL is probably that they expose their mutation, rather than hiding it in the architecture like pure functional languages. In C++ you just have to hide the infrastructure yourself.

humanrebar 13y ago
The overhead that is assumed unimportant by most functional languages (copying is cheap, GC is fine, etc.) is intolerable in key situations and problem domains. In C++ all overhead must be optional. That being said, nearly all C++ applications can benefit from immutable classes, algorithms that take closures, and so on. But C++, like C before it, is really just an abstraction of the hardware and OS below it. That hardware mutates. That pool of memory changes size and locality. The closer your problem domain is to the metal (especially drivers and highly-optimized code), the more you appreciate mutable state, at least given the current state of computing.
- pkolaczk 13y ago
  Dealing with complex immutable data structures without GC is either extremely hard or inefficient (and usually both). C++ standard library does not offer any helping hand here either. Additionally C++ logical memory model (flat, uniform memory) does not describe the hardware memory model well - it is already an abstraction. An memory access isn't uniform and mutations can cost you really very much. In some cases immutable structures + little copying is often the way to go, especially when we aim at parallelization.

deleted 13y ago

[deleted]

blt 13y ago

Before C++11, if you wanted to pass a function with closure-like behavior to an STL algorithm, you had to write a little class with operator() overloaded. It was a huge pain in the ass, lots of boilerplate code. Most programmers didn't bother and wrote plain loops. Now with C++11 lambdas, std::algorithm is much nicer to use.