That's a limited view. One could very well make it's own class with malloc()/free() in the constructor/destructor, without exposing any pointer like interface. This can be done without reference counting, contrary to what the faq suggests.

the C++ STL takes away the burden of 'hard to implement'. It's definitely hard to do right, but the STL has solved that problem.

I'm sure garbage collection has it's place and use, but the site seems a bit biased against alternatives. Garbage collection definitely has it's scaling challenges for large code-bases.

pcwalton is right. RAII is just a language semantics to make memory management implicit.

(I feel a little bit cynical today and will say it's typical to C++'s attitude (as opposed to e.g. C): Let users make overcomplex programs more easily, by papering over all the insanity, instead of forcing them to make a clean design).

If there's anything like "memory management" in RAII, then it's the idea of deallocating objects in the reverse order of their allocation. That hardly deserves a note, though, since it doesn't say anything about how the memory is allocated.

(And as usual with OOP, you end up with terrible inefficiencies (too much allocation in this case), since the program is split into needlessly isolated parts in a futile attempt to make them "self-contained". In the end, what that does is also make everything less efficient and more complicated. And redundant, if you care to look at what actually happens as opposed to what the programmer writes).

>And as usual with OOP, you end up with terrible inefficiencies

That is not a property of OOP. Counterexample: C++ is OOP and it's not inefficient. It's a property of having no control over the memory layout and no stack allocation. If Java gets value types it's efficiency would massively increase while still remaining OOP.