tags:

views:

173

answers:

5

Most of my C++ programming experience has been projects for school. In that way, our usage of external libraries (ie boost) has been either prohibited or discouraged. Therefore we could not use smart pointers unless we wanted to write our own, which was usually beyond the scope of the projects. I'm just wondering in real world projects, how much memory management is actually done manually?

I guess this is sort of a vague question. I'm just wondering how memory management is usually done in real world projects.

+3  A: 

In the few projects I wasn't allowed boost, on one of them, I did roll a rudimentary smart pointer.

That said, in the real world, use boost. Use third party libraries. If a wheel is out there, don't reinvent it. You'll be more productive, and you'll spend less time tediously writing code someone else has already written.

Thanatos
+2  A: 

Depends what you mean by "memory management".

Obviously, a strict definition means "all the time", since automatic variables (stack allocated) is a memory thing. You probably didn't intend that.

On the other side, there is raw new and delete usage. This should never happen, but probably happens in "common" C++ anyway. It's bad practice, sloppy, and easily solvable with containers. One can literally copy and paste a smart pointer implementation from somewhere and be done, no excuse.

In the middle, ideally all "management" is done automatically, with containers. The only management that might need to be done is breaking cyclic dependencies or making your own container classes.

In my own projects, I only ever use new and delete when I'm making a utility class so I never have to new and delete again. After that, I only use new when it goes directly into some container.

GMan
+6  A: 

On legacy code there's usually a lot of manual memory management. If someone hadn't take the time to refactor it you can find a lot of naked news and deletes, just happily waiting to leak somewhere.

I believe most recent, well written, software in C++ usually do use smart pointers, RAII, and so on. Manual memory management is error prone.

Vitor Py
Smart pointers just attach the scope of an object to that of a local variable (the smart pointer)... its not magic. Making safe raw pointers in code that uses exceptions is very verbose at best, and incorrect at worst.
Akusete
@Tim It's very difficult to manually manage memory in a few situations - like when a exception is thrown.
Vitor Py
@Vitor Just use a finally block. OH WAIT. *glares at C++*
Michael Mrozek
@Tim: I'd hate to have to maintain your code.
GMan
@Tim: auto_ptr's have nothing to do with managed memory (Garbage Collectors). They do not incur any overhead other than the simple checking you would have to do anyway yourself and you have complete flexibility to do anything you would with raw pointers.
Akusete
@Tim: There's more to it than simple style or preference. Code that manages resources explicitly is either unsafe or unclean, because you're not exception-safe/forgetful, or putting catches, deletes, and re-throws everywhere. Using a smart pointer simply takes what you would have done and does it for you guaranteed; no disadvantage to that. Certainly no performance problems, on any modern compiler.
GMan
Chose because of the comments and the most concise answer
Falmarri
In my experience even with smart pointers C++ requires you to constantly be aware of memory management. Who owns what? When can I safely delete this? Debugging problems with "smart pointers" can be challenging.
seand
@seand: The entire point of containers is to never ask "who owns this" or "can I delete this?". A container will know both of those things, and does the appropriate action automatically.
GMan
A: 

In the real world there is both. You'll most likely see more project code out there that desn't make use of smart pointers. The use of new and delete is most prevalent.

That being said, more and more programmers are using boost and smart pointers in their projects now and I've seen some code refactored to use boost::shared_ptr as well

Matt H
A: 

It is also worth mentioning that shared_ptr made it into the standard library in 2003 as std::tr1::shared_ptr. Or at least, if it isn't officially in the library, it is shipping with all the C++ compilers I've used recently.

Richard Wolf
To be exact, the contents of std::tr1 (or C++ Technical Report 1) aren't in the standard as they are only proposed additions. That's why they are on their own namespace to distinguish them from the standard library. However, they will be on the next C++ standard, C++0x.
vtorhonen
@vtorhonen: updated
Richard Wolf