How to manage member variable in C++

Question

In brief, my question is about member variables as pointers in unmanaged C++.

In java or c#, we have "advanced pointer". In fact, we can't aware the "pointer" in them. We usually initialize the member of a class like this:

member = new Member();

or

member = null;

But in c++, it becomes more confusing. I have seen many styles: using new, or leave the member variable in stack.

In my point of view, using boost::shared_ptr seems friendly, but in boost itself source code there are news everywhere. It's the matter of efficiency，isn't it?

Is there a guildline like "try your best to avoid new" or something?

EDIT

I realize it's not proper to say "leave them in stack", here's a more proper way to say: when i need an object to be my member variable, should i prefer a object than a object*?

Answer 1

The Boost source code is not a good example for how you should write your source code. The Boost libraries are designed to wrap up all the tedious, difficult, and error-prone code so that you don't have to worry about it in your code.

Your best bet is to follow two general rules in your code:

• Don't use pointers where you don't need to use pointers
• Where you do need to use pointers, use smart pointers (like shared_ptr or scoped_ptr)

Answer 2

Yes, there is a guideline - only use dynamic allocation when you must. A lot of the time yo can and should be using values, not pointers. For example, you should almost always be using:

vector <string> v;

rather than:

vector <string *> v;

and allocating the strings dynamically.

Answer 3

The guide to the language by Stroustrup:

Scott Meyers's triple are quite useful: Effective C++, More Effective C++, and Effective STL.

Also see these questions:
- https://stackoverflow.com/questions/155762/best-c-resource
- Java FAQ equivalent of C++ FAQ lite?
- C++ : handle resources if constructors may throw exceptions (Reference to FAQ 17.4]
- What C++ pitfalls should I avoid?
- New to C++. Question about constant pointers

Answer 4

Certainly it won't kill you if you do a single new in the constructor, and a single delete in the destructor. In a simple case like that, using smart pointers is just pointless overhead.

If you go more complicated, or if you are paranoid about exception safety, smart pointers may very well be a good idea.

Answer 5

The benefit of using shared_ptr is that it is a "smart pointer" that does not require an explicit delete to free the memory. Otherwise, if you use new you will have to explicitly call delete to free the allocated memory once the object is no longer required.

Answer 6

In C++ it is a matter of choice to the developer. There is more power but also more responsibility that goes with it.

Example:

A class that declares an object with internal storage of arbitrary size.

1. If you design this class to allocate worst case storage at instantiation you can avoid pointers altogether. But the cost is heavy in terms of memory usage for the average case.

2. If you design the class to allocate memory based on its needs you might choose to use pointers. Then each instance will take only what it needs from the heap. But you must use care to avoid pointer bugs.

3. If you design the class to allocate memory based on its needs you might still be able to avoid pointers using abstractions for the memory (i.e. auto_ptr or a custom buffer scheme, etc.).

So a guideline might be to explore the options available before resorting to naked pointers in application code. The balance might be different for library code since it will be more limited in scope, possibly more performance sensitive, and (hopefully) better tested.

Answer 7

You may want to use the C++ STL class "autoptr" to take care of managing your memory.

Also, in C++, if it is a member variable, it doesn't have to be a pointer.

class MyClass
{
    MyClass();

    MyMember a;
    MyMember* b;
    std::auto_ptr<MyMember> c;
}

MyClass::MyClass()
{
    // constructer
    // a is now instantiated -- I don't have to do anything
    b = new MyMember(); // I'll have to delete it in the destructor
    c.reset(new MyMember()); // I won't have to delete it in the destructor
}