Is using pointers in C++ always bad?

Question

I was told to avoid using pointers in C++. It seems that I can't avoid them however in the code i'm trying to write, or perhaps i'm missing out on other great C++ features.

I wish to create a class (class1) which contains another class (class2) as a data member. I then want class2 to know about class1 and be able to communicate with it.

I could have a reference to class1 as a member in class2 but that then means I need to provide a reference to class1 as a parameter in the constructor of class2 and use initialiser lists which I don't want. I'm trying to do this without needing the constructor to do it.

I would like for class2 to have a member function called Initialise which could take in the reference to class1, but this seems impossible without using pointers. What would people recommend here? Thanks in advance.

The code is completely simplified just to get the main idea across :

class class1
{
    public:
        InitialiseClass2()
        {
            c2.Initialise(this);
        }

    private:
        class2 c2;

};

class class2
{
    public:
        Initialise(class1* c1)
        {
            this->c1 = c1;
        }

    private:
        class1* c1;

};

Answer 1

No, using pointers in C++ is not bad at all, and I see this anti-advice over and over again. What is bad is managing pointers by yourself, unless you are creating a pointer-managing low-level entity.

Again, I shall make a very clear distinction. Using pointers is good. Very few real C++ programs can do without USING pointers. Managing pointers is bad, unless you are working on pointer manager.

Answer 2

First of all whenever you have a circular dependency in your design think about it twice and make sure it's the way to go. Try to use the Dependency inversion principle in order to analyze and fix your dependencies.

I was told to avoid using pointers in C++. It seems that I can't avoid them however in the code i'm trying to write, or perhaps i'm missing out on other great C++ features.

Pointers are a powerful programming tool. Like any other feature in the C++ (or in any programming language in general) they have to be used when they are the right tool. In C++ additionally you have access to references which are similar to pointers in usage but with a better syntax. Additionally they can't be null. Thus they always reference a valid object.

So use pointers when you ever need to but try to avoid using raw pointers and prefer a smart pointer as alternative whenever possible. This will protect you against some trivial memory leak problems but you still have to pay attention to your object life-cycle and for each dynamically allocated object you should know clearly who create it and when/whom will release the memory allocated for the object.

Pointers (and references) are very useful in general because they could be used to pass parameters to a method by reference so you avoid passing heavy objects by value in the stack. Imagine the case for example that you have a very big array of heavy objects (which copy/= operator is time consuming) and you would like to sort these objects. One simple method is to use pointers to these objects so instead of moving the whole object during the sorting operation you just move the pointers which are very lightweight data type (size of machine address basically).

Answer 3

A pointer can be nullptr whereas a reference must always be bound to something (and cannot be subsequently re-bound to something else).

That's the chief distinction and the primary consideration for your design choice.

Memory management of pointers can be delegated to std::shared_ptr and std::unique_ptr as appropriate.

Answer 4

well, I never had the need to 2 classes to have reciprocal reference and for good reasons, how do you know how to test those classes? If later you need to change something in the way the 2 classes communicates you will probably have to change code in both classes). You can workaround in many ways:

1. You may need in reality just 1 class ( you have broken into much classes)
2. You can register a Observer for a class (using a 3rd class, in that case you will end up with a pointer, but at least the 2 classes are less coupled and it is easier test them).
3. You can think (maybe) to a new interface that require only 1 class to call methods on the other class
4. You could pass a lambda (or a functor if you do not have C++11) into one of the methods of the class removing the need to a back reference
5. You could pass a reference of the class inside a method.
6. Maybe you have to few classes and in reality you need a third class than communicates with both classes.
7. It is possible you need a Visitor (maybe you really need multiple dispatch)

Some of the workarounds above need pointers, some not. To you the choice ;)

NOTE: However what you are doing is perfectly fine to me (I see you do some trickery only in constructors, but probably you have more omitted code, in wich case that can cause troubles to you). In my case I "register" one class into another, then after the constructor called I have only one class calling the other and not viceversa.

Answer 5

this seems impossible without using pointers

That is incorrect. Indeed, to handle a reference to some other object, take a reference into a constructor:

class class2
{
    public:
        class2(class1& c1)
           : c1(c1)
        {}

    private:
        class1& c1;
};

The key here is to initialise, not assign, the reference. Whether this is possible depends on whether you can get rid of your Initialise function and settle into RAII (please do!). After that, whether this is actually a good idea depends on your use case; nowadays, you can almost certainly make ownership and lifetime semantics much clearer by using one of the smart-pointer types instead — even if it's just a std::weak_ptr.

Anyway, speaking more generally.

Are pointers "always" bad? No, of course not. I'd almost be tempted to say that managing dynamic memory yourself is "always" bad, but I won't make a generalisation.

Should you avoid them? Yes.

The difference is that the latter is a guideline to steer you away from manual memory management, and the former is an attempted prohibition.