3 ms·

That is very true of modern C++ because the idiomatic way of handling the acquisition and release of all resources is to acquire in a constructor (typically eit

That is very true of modern C++ because the idiomatic way of handling the acquisition and release of all resources is to acquire in a constructor (typically either explicitly for a single resources or implicitly by including another object that acquires resources as a member variable for multiple resources). C++ doesn't completely free you from considering whether a type allocates memory on the stack or on the heap, but it does let you limit which code needs to concern itself with where values are allocated to a very small portion of the code. Most code written to work against a std::vector will also work against a std::array unless it is relying on the ability of a std::vector to dynamically resize.

klmr 9y ago
> C++ doesn't completely free you from considering whether a type allocates memory on the stack or on the heap You’re completely right but the way this is phrased shows a common misconception about C++/RAII: it was never about freeing the programmer from considering how to manage memory. Rather, it was about automating the mechanics behind these considerations, and adding a layer of type safety (which C++11 tremendously improved). If you don’t want to think about memory management, use a garbage collected language (but accept that it doesn’t scale to all scenarios). C++ forces you to think about resource management, it just makes the implementation of resource management vastly easier than C.