Question

I recently came across some C++ code that looked like this:

class SomeObject
{
private:
    // NOT a pointer
    BigObject foobar;

public:
    BigObject * getFoobar() const
    {
        return &foobar;
    }
};

I asked the programmer why he didn’t just make foobar a pointer, and he said that this way he didn’t have to worry about allocating/deallocating memory. I asked if he considered using some smart pointer, he said this worked just as well.

Is this bad practice? It seems very hackish.

Answer 1

Is this bad practice? It seems very hackish.

It is. If the class goes out of scope before the pointer does, the member variable will no longer exist, yet a pointer to it still exists. Any attempt to dereference that pointer post class destruction will result in undefined behaviour – this could result in a crash, or it could result in hard to find bugs where arbitrary memory is read and treated as a BigObject.

if he considered using some smart pointer

Using smart pointers, specifically std::shared_ptr<T> or the boost version, would technically work here and avoid the potential crash (if you allocate via the shared pointer constructor) – however, it also confuses who owns that pointer – the class, or the caller? Furthermore, I’m not sure you can just add a pointer to an object to a smart pointer.

Both of these two points deal with the technical issue of getting a pointer out of a class, but the real question should be “why?” as in “why are you returning a pointer from a class?” There are cases where this is the only way, but more often than not you don’t need to return a pointer. For example, suppose that variable needs to be passed to a C API which takes a pointer to that type. In this case, you would probably be better encapsulating that C call in the class.