Change member object to pointer to resolve circular dependency

Question

So I've searched for an answer to this and I've found lots of relevant info but nothing answering this exactly.

I've seen lots of advice about when to use pointers to objects saying just use an actual object instead whenever possible. I've also seen advice about circular dependencies saying to not include a .h file in a .h file whenever possible. I've fixed a lot of my code (in terms of circular dependencies) by switching object members of classes to pointers to the objects. I end up with a lot of pointer members, seemingly going against the first piece of advice.

My question is, is it a bad idea to just switch all my object members to pointers to resolve circular dependencies? Or does that signify a bad structuring of my classes and that I need a redesign? Or maybe more precisely, does having a circular dependency justify the changing of an object member to a pointer? Or would it come down to each case too specifically?

I apologize if this doesn't make any sense as I am not an experienced programmer.

Thanks

Did you consider using `std::weak_ptr`? There is a plenty of info around of how the use of `std::weak_ptr` to avoid pointer circular dependency. — wesley.mesquita, Feb 05 '14 at 19:04

bobah · Answer 1 · 2014-02-05T18:45:59.710

Circular dependency means your hierarchy or interfaces design, or duties segregation is suboptimal. If you have them it does not really matter what trick you use to have compiler still build them and application to start, I personally would do std::shared_ptr<T*> like:

namespace elsewhere { class T; }
namespace here {
    class A {
        std::shared_ptr<T> _t;
    }
}

and elsewhere

namespace here { class A; }
namespace elsewhere {
    class T {
        std::shared_ptr<A> _a;
    }
}

On the subject in general, circular dependency is always something like

[Apriv,Acoupled]<-->[Bcoupled, Bpriv]

which is usually easily transformable to a normalized form

[Apriv]<--[Acoupled,Bcoupled]-->[Bpriv]

score 0 · Answer 2 · edited May 23 '17 at 12:21

I've never heard of "it is bad to have many pointers, try to use objects instead"... pointers are "dangerous" if you don't know how to use them but think of a class like the following:

class myClass {
private:
  GIGANTIC_OBJECT obj;
}

if myClass gets allocated/deallocated a lot... would you rather have a big object or a pointer to one of them?

Circular dependencies of header files is another problem (you'll have to include the header anyway if you're pointing to an object unless you're using opaque pointers) but if you're encountering it, that means you have some design deficiencies, e.g.

foo.h

class foo {
public:
   bar b;
};

bar.h

class bar {
public:
   foo f;
};

the above is illegal and you could easily avoid it with

foo.h

class bar; // forward declaration
class foo {
   ...
   bar *b;
   ...
};

bar.h

class foo; // forward declaration
class bar {
   ...
   foo *f;
   ...
};

(https://stackoverflow.com/a/4816751/1938163)

Also: the use of the #pragma once directive can help reducing multiple-declarations.

To summarize: I don't think having more pointers or objects is a one-for-all rule, it depends on the case (e.g. passing large objects via value to a function is stupid) and circular dependencies for headers is a relatively dislinked problem that usually should make you think "did I design it correctly? / Am I doing something wrong?".

Change member object to pointer to resolve circular dependency

2 Answers2