You mean like manually having to free memory, close files, things of this sort? If so, I'd say the minimum and typically less than most other languages I've used, especially if we generalize that not just to "memory management" but "resource management." In that sense, I actually think C++ requires less manual resource management than, say Java or C#.
It's mainly due to destructors which automate destroying the resource (memory or otherwise). Typically the only time I have to free/destroy a resource manually in C++ is if I'm implementing a vlow-level data structure (something most people don't need to do) or using a C API where I just spend a little time wrapping the C resource that needs to be manually freed/destroyed/closed into a RAII-conforming C++ wrapper.
Of course if a user requests to close an image in an image editing software, I have to remove the image from a collection or something. But hopefully that doesn't count as "memory" or "resource" management of a kind that matters in this context, since that's pretty much required in any language if you want to free the memory associated with that image at that time. But again all you have to do is remove the image from the collection and the image destructor takes care of the rest.
Meanwhile if I compare to, say, Java or C#, you often find people having to close files manually there, manually disconnect sockets, set object references to null to allow them to be garbage collected, etc. There's a whole lot more manual memory and resource management in those languages if you ask me. In C++ you often don't even need to unlock
a mutex manually, since the mutex locker will do that for you automatically when the mutex goes out of scope. For example, you should never have to do things like this in C++:
System.IO.StreamReader file = new System.IO.StreamReader(path);
try
{
file.ReadBlock(buffer, index, buffer.Length);
}
catch (System.IO.IOException e)
{
...
}
finally
{
if (file != null)
file.Close();
}
There's no need to be doing things like closing files manually in C++. They end up closing themselves automatically the instant they go out of scope whether they go out of scope as a result or normal or exceptional execution paths. Similar thing for memory-related resources like std::vector
. Such code like file.Close()
above would often be frowned upon since, especially in the context of a finally
block, that suggests the local resource needs to be freed manually when the whole mindset around C++ is to automate that.
In terms of manual memory management, I'd say C requires the maximum, Java/C# a medium amount, and C++ the minimum among these. There are many reasons to be a bit shy of using C++ since it's a very difficult language to master, but memory management shouldn't be one of them. To the contrary I actually think it's one of the easiest languages out there in this one aspect.
Of course C++ does let you start manually allocating memory and invoking operator delete/delete[]
to manually free memory. It also lets you use C functions like malloc
and free
. But that's ancient-style coding practices of a kind which I think became obsolete long before people give credit, since Stroustrup was advocating RAII before he even coined the term from very early on. So I don't even think it's fair to say "modern C++" automates resource management, because that was supposed to be the purpose all along. You can't practically get exception-safety otherwise. It's just that a lot of misguided developers during the early 90s tried to use C++ as like C with objects, often completely ignoring exception-handling, and it was never supposed to be used that way. If you use C++ the way it was practically always intended to be used, then memory management is totally automated and generally not something you have to manually deal with (or should be dealing with) much at all.