-1

Should they be declared in the .cpp or .h files?

Example 1:

A.h
#include "B.h"
#include "C.h"

class A
{
    void someFunction();
    B   b;
    C   c;
}

Example 2:

A.cpp
#include "B.h"
#include "C.h"

A::someFunction()
{
    B   b;
    C   c;
    // Do something with b and c.
}

Example 3:

A.cpp
#include "B.h"
#include "C.h"

B   b;
C   c;

A::someFunction()
{
    // Do something with b and c.
}

Should they only be declared in the function that is using them (example 2) or can they be declared at the top of the file under the header includes like in example 3?

C3PO
  • 11
  • 7
  • example 1 is not an alternative to the other two (actually all three are completely different cases), also i see no circular dependency in there. – 463035818_is_not_an_ai Sep 23 '16 at 09:17
  • Maybe [one of **these**](https://stackoverflow.com/search?q=%5Bcpp%5D+circular+dependency) covers what you're missing. Did you look? – WhozCraig Sep 23 '16 at 09:20
  • @tobi303 can you explain when or if any of those cases should be used? – C3PO Sep 23 '16 at 09:21
  • My question is less about circular dependencies than how/where class objects should be used – C3PO Sep 23 '16 at 09:23
  • 1
    I dont really understand the question. Ex1 is member variables, Ex2 is variables in function scope and Ex3 is global variables, all completely different scopes. As Bathsheba says in his answer, you declare them where you need them and if possible in the most narrow scope (and avoid globals if possible) – 463035818_is_not_an_ai Sep 23 '16 at 09:26
  • @tobi303 thanks, done – C3PO Sep 23 '16 at 09:39

2 Answers2

1

Declare them with the narrowest scope as possible. If a class is only used in a single translation unit, then declare and define it in the source file. Typically you'd only declare a class in a header file if it's declaration is required by more than one transation unit.

The normal way of dealing with circular dependencies is to use a forward class declaration.

Bathsheba
  • 231,907
  • 34
  • 361
  • 483
1

All of those examples are for different use cases:

A.h
#include "B.h"
#include "C.h"

class A
{
    void someFunction();
    B   b;
    C   c;
}

This adds objects b and c of types B and C respectively to your class A. Any object of type A will now have access to these 2 other objects. (just not outside of the class since they're implcitly private). This is vastly different from example 2 & 3 since it doesn't actually define any variables yet until you instantiate an object of A.

Example 2:

A.cpp
#include "B.h"
#include "C.h"

A::someFunction()
{
    B   b;
    C   c;
    // Do something with b and c.
}

This is usually the best scenario when you only need to use b and c inside someFunction and their changes don't have to be visible to the outside of the function. Note that their lifetimes are until the end of the function.

Example 3:

A.cpp
#include "B.h"
#include "C.h"

B   b;
C   c;

A::someFunction()
{
    // Do something with b and c.
}

Here, b and c are both global variables, globals are usually frowned upon because they make it hard to track what part of your code is doing what modification to these variables. A better alternative would be passing them around and defining them in main() if their lifetime should be the for entirety of the program.

Community
  • 1
  • 1
Hatted Rooster
  • 35,759
  • 6
  • 62
  • 122
  • What if say, both a function in A and B are changing the values of members in class C but the changes they make has to be visible outside the function? Should I use 'static' declarations in C or something like b.c.set()? – C3PO Sep 23 '16 at 09:36
  • @C3PO I am afraid we have kind of a [XY problem](http://meta.stackexchange.com/questions/66377/what-is-the-xy-problem) here. I suggest you to maybe post a new question with the actual problem you are facing and not some abstraction of it. It seems like you simply have to pass a `C` instance by reference to the function to make changes visible outside of the function, but I might be wrong – 463035818_is_not_an_ai Sep 23 '16 at 09:38