3 ms·

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 langu

by 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.

by nly 13y ago

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.