Forward Declaration?, Include guard?, or something else?

Question

I have a parent class called Token

I have two children classes, ErrorToken and EndToken. Each one of those classes needs to be able to create an object of the other, and return it through a function call. Each one has their own seperate header class.

So, ErrorToken needs to be able to create a new EndToken object and return it, and EndToken needs to be able to create a new ErrorToken object and return it.

What is going to be the best way to succeed at doing this? I would prefer if it was as cross compiler compatible as possible so I don't want to use pragma once. (but thats essentially what I'm looking for).

Ideally I'd like to be able to do something like this...

#ifndef ErrorToken
#include "ErrorToken.h"
#endif

But that never seems to work (and my guess is that that is wrong? can someone help me understand why?).

My understanding of forward declaration is that it only works on function signatures and pointers (is that correct?), so I don't think that will work for my situation since I need it to be able to run the constructor...or does the compiler just need to be aware that the constructor exits at that moment?

Use forward declarations in the header files, and include the necessary headers in the implementation files. — juanchopanza, Sep 12 '13 at 08:19
What strange compilers are you planning on using that `#pragma once` is not supported? Every compiler I know supports it. — nikolas, Sep 12 '13 at 08:21

Kerrek SB · Accepted Answer · 2013-09-12T09:07:59.257

2

Well, use forward declarations. As you said, there are millions of explanations out there, and now there are millions and one:

ErrorToken.h:

#ifndef H_ERROR_TOKEN
#define H_ERROR_TOKEN

#include "Token.h"

class EndToken;

class ErrorToken : public Token
{
public:
    EndToken makeEndToken();
};

#endif

EndToken.h:

#ifndef H_END_TOKEN
#define H_END_TOKEN

#include "Token.h"

class ErrorToken;

class EndToken : public Token
{
public:
    ErrorToken makeErrorToken();
};

#endif

In each implementation file, you can now happily include both headers:

#include "ErrorToken.h"
#include "EndToken.h"

ErrorToken EndToken::makeErrorToken()
{
    return ErrorToken();   // example
}

EndToken ErrorToken::makeEndToken()
{
    return EndToken();
}

As @James Kanze pointed out, you might be confused about how C++ works. The following code may be more in line with the kind of behaviour you expect from Java, and makes more sense in a polymorphic design way:

class Token { virtual ~Token()  {} };

class ErrorToken : public Token
{
    std::unique_ptr<Token> makeEndToken();
};

class EndToken : public Token
{
    std::unique_ptr<Token> makeErrorToken();
};

std::unique_ptr<Token> EndToken::makeErrorToken()
{
    return { new ErrorToken; }
}

std::unique_ptr<Token> ErrorToken::makeEndToken()
{
    return { new EndToken; }
}

Since you're only handling objects via base pointers, the headers don't need to know anything about other derived classes. (I leave it to you to subdivide the code into files; each block goes into a separate file.)

edited Sep 12 '13 at 09:07

answered Sep 12 '13 at 08:31

Kerrek SB

464,522
92
875
1,084

You might point out _why_ you changed the name of his include guard. (Using `ErrorToken` as an include guard for a header which defines a class `ErrorToken` isn't going to work very well.) – James Kanze Sep 12 '13 at 08:50
Another point, not related to his question (but since he's coming from a Java background, maybe worth pointing out): as written, your functions return by value. This is somewhat exceptional for objects in an inheritance hierarchy (although it may be justified); most of the time, you'd return a pointer (`ErrorToken*`). – James Kanze Sep 12 '13 at 08:54
@JamesKanze: I didn't even notice that :-) – Kerrek SB Sep 12 '13 at 09:02
@JamesKanze: This whole question is tenuous at best. "Normally" you'd return a base pointer, and the entire question would go away... – Kerrek SB Sep 12 '13 at 09:03
Thanks for the input... what are the benefits of returning a pointer vs by value? Does it simply prevent the program from having to copy the object? – CamHart Sep 13 '13 at 05:37
http://stackoverflow.com/a/3431492/2080104 This seems to make me think it's okay to return objects? Or am I way off? – CamHart Sep 13 '13 at 05:48

score 1 · Answer 2 · edited May 23 '17 at 11:50

Why is your

#ifndef ErrorToken

wrong? First, put it in the header file, second make sure something actually defines ErrorToken

Include guards and forward declarations might get you out of this hole:

//"ErrorToken.h"
#ifndef ERROR_TOKEN_INCLUDED
#define ERROR_TOKEN_INCLUDED

class EndToken;

class ErrorToken
{
public:
    EndToken DoSomething();
};
#endif

//"EndToken.h"
#ifndef END_TOKEN_INCLUDED
#define END_TOKEN_INCLUDED
class ErrorToken;

class EndToken
{
public:
    ErrorToken DoSomething();
};
#endif

There have been several previous discussions on circular dependencies: here, here and here
You can then do the bulk of the work in the cpp file, where you include the other header, so it knows the full class definition, rather than just the forward declaration, and can use it.
Step back first though and ask, "Do they really need to know about each other?"

I would strongly suggest a more elaborate naming convention for the include guard; say something like ERRORTOKEN_H. As it is, your code won't compile, because you've `#define`d the name of the class to an empty string. — James Kanze, Sep 12 '13 at 08:48

Forward Declaration?, Include guard?, or something else?

2 Answers2