In C++, how much programmer time is spent doing memory management

Question

People who are used to garbage collected languages are often scared of C++'s memory management. There are tools, like auto_ptr and shared_ptr which will handle many of the memory management tasks for you. Lots of C++ libraries predate those tools, and have their own way to handle the memory management tasks.

How much time to you spend on memory management tasks?

I suspect that it is highly dependent on the set of libraries you use, so please say which ones your answer applies to, and if they make it better or worse.

Answer 1

Modern C++ makes you not worry about memory management until you have to, that is until you need to organize your memory by hand, mostly for optimization purpose, or if the context forces you to do it (think big-constraints hardware). I've written whole games without manipulating raw memory, only worriing about using containers that are the right tool for the job, like in any language.

So it depends on the project but most of the time it's not memory management that you have to handle but only object life-time. That is solved using smart pointers, that is one of idiomatic C++ tool resulting from RAII.

Once you understand RAII, memory management will not be a problem.

Then when you'll need to access raw memory, you'll do it in very specific, localized and identifiable code, like in pool object implementations, not "everywhere".

Outside of this kind of code, you'll not need to manipulate memory, only objects lifetime.

The "hard" part is to understand RAII.

Answer 2

Memory management is used to scare children, but it is only one kind of resource that a programmer has to look after. Think file handles, network connections, other resources that you obtain from the OS.

The languages that support garbage collection usually not only ignore the existence of these resources, but they also make it harder to handle these properly by not providing a destructor.

So, in short, I'd suggest not that much of a C++ developer's time is spent worrying about memory management. As klaim's answer indicates, once you get a handle on RAII, the rest is just reflex.

Answer 3

Pretty much none. Even old technologies like COM, you can write custom deleters for the Standard pointers that will convert them in a very short time. For example, std::unique_ptr can be converted to uniquely hold a COM reference with five lines of a custom deleter. Even if you have to manually write your own resource handler, the prevalence of knowledge like SRP and copy-and-swap makes it relatively easy to write a resource managing class to use forever more.

The reality is that shared, unique, and non ownership all ship with your C++11 compiler, and you just have to write small adapters to make them work even with old code.

Answer 4

When I was a C++ programmer (a long time ago), I spent a long time worry about memory management bug when trying to fix hard to reproduce bugs.

With modem C++, memory management is a lot less of an issue, but can you trust everyone on a large team to get it right. What is the cost/time of:

• Training (not many programers arive with a good understanding of the issues)
• Code reviews to find memory management issues
• Debugging of memory management issues
• Always having to keep in mind that a bug in one part of the app, may be due to a memory management issue in a unrelated part of the app.

So it is not just the time spending “doing”, this is more of an issue on large projects.

Answer 5

I use boost and TR1 libraries a lot, and they make memory management in the strict sense (new/delete) a non-issue. On the other hand, memory allocation in C++ is not cheap, and one must pay attention to where these fancy shared pointers are created. You end up using workspaces a lot, or working with stack-based memory. In general, I'd say that it's mostly a design problem, not an implementation problem.

Answer 6

how much time does it take as a client? very little, once you get the hang of it. when a container manages lifetime and references, it's really very easy. imo, it's far simpler than manual reference counting, and it's practically transparent if you consider the container you use as documentation which the compiler conveniently prevents you from performing invalid ownership transfers in a well designed typesafe system.

most of the time i spend (as a client) is spent containing types from other apis, so they function well within the context of your programs. example: this is my ThirdPartyFont container, and it supports these features, and implements destruction this way, and reference counting this way, and copying this way, and.... Many of those constructs need to be in place, and it's often the logical place to put them. whether you want to include that as time or not depends on your definition (the implementation needs to exist when interfacing with these apis, anyway, right?).

after that, you will need to take memory and ownership into consideration. in a lower level system, that's good and necessary, but it can take some time and scaffolding to implement how you should move things around. i don't see it as a pain since this is a requirement of a lower level system. ownership, control, and responsibility are evident.

so we can turn that towards c based apis which use opaque types: our containers allow us to abstract all the little implementation details of managing the lifetime and copying of those opaque types, which ultimately makes resource management very very simple and saves time, defects, and reduces implementations.

it's really very simple to use these - the problem (coming from GC) is that you have to now consider your resources' lifetimes. if you get it wrong, it can take a lot of time to solve. learning and integrating explicit lifetime management is understandably complex in comparison (not for all people) -- that's the real hurdle. once you are comfortable controlling lifetimes and using good solutions, then it's really very easy to manage resource lifetimes. it's not a significant part of my day (unless a difficult bug has crept in).

if you're not using containers (auto/shared pointer), then you're just pleading for pain.

i've implemented my own libraries. it takes me time to implement those things, but most people reuse (which is usually a good idea).

Answer 7

Pretty much zero, except for some overhead required to run a memory leak detection tool as a part of automated tests which mostly run overnight anyway.

Answer 8

Depends on the senior technical leads in the team. In some companies ( including mine ), there is no concept called smart poiner. It is considered fancy. So, people simply put deletes all over the place and there is a drive for memory leak fixing for every 2 months. New wave of delete statements arrive everywhere. So, depends on the company and the kind of people who work there.