There is a certain elegance to time-tested C APIs that show exactly how data structures are managed. One of the things you can lose in OO implementations is th

There is a certain elegance to time-tested C APIs that show exactly how data structures are managed. One of the things you can lose in OO implementations is the ability to efficiently store data, or even understand where your memory is going. (And I feel that the varying semantics between languages don’t help, e.g. people that were used to doing "new X()" for everything in Java move to C++ and keep trying to "new" things that don’t need to be sent to "new".) It is important to have the option to deviate from “objects” in projects that can require significant memory. I would not allow objects to wrap absolutely everything, being passed all around the system, to the point that it’s impossible to control the biggest users of memory. As a simple example, imagine an object that strictly encapsulates storage of “64-bit int plus bool”. At a small scale, the wasted space is an implementation detail but for a few million objects you have a pretty ridiculous memory footprint. A fancy encapsulated object probably gives no option to avoid this, such as “put your array of million 64-bit values over here, and your buckets for bits over there”. When this happens enough times, you have holes all over the place and it’s almost too late (where do you start to fix it?). That is also the type of design that can consume shockingly more memory when moving from 32-bit to 64-bit, e.g. some class that had moderate holes with 32-bit pointers has bigger holes with 64-bit pointers.