I have recently been trying to convert a codebase to C++20 modules using GCC 11. However, I got stuck on the following situation. First, here is how it was done using headers:
A.h
class B;
class A {
public:
void f(B& b);
};
A.cpp
#include "A.h"
#include "B.h"
void A::f(B& b)
{
// do stuff with b
}
(the contents of B.h is not important here)
The thing to note is the forward declaration of B. Not everybody using A should care about B, so I used a forward declaration to stop recompiling from happening. With headers, this situation works perfectly.
The issue is when trying to convert this code to modules. The main issue is that entities are tied to the module they are declared in, so forward declaring in A.h is impossible. I tried forward declaring in the global module, but then the compiler still complained that the definition of B was in a different module than its declaration. I also tried having a third module that just contained the forward declaration of B, but this was still declaring and defining B in two different modules. So, my main question is: how can I forward declare something from a module outside of it? I would also be satisfied with a way that ends up producing the same effect: that users of A don't need to be recompiled when B changes.
While searching, I found a few places talking about similar situations, but they all didn't work for some reason. The reasons they didn't work:
Edit: in response to a comment, here are the details for a few of the things I have tried:
Attempt 1: Forward declare B in A.mpp
A.mpp
export module A;
class B;
export class A {
public:
void f(B& b);
};
B.mpp
export module B;
export class B {};
A.cpp
module A;
import B;
void A::f(B& b)
{
// do stuff with b
}
When doing this, gcc errors with
A.cpp:4:11: error: reference to ‘B’ is ambiguous
4 | void A::f(B& b)
| ^
In module B, imported at A.cpp:2:
B.mpp:3:14: note: candidates are: ‘class B@B’
3 | export class B {};
| ^
In module A, imported at A.cpp:1:
A.mpp:3:7: note: ‘class B@A’
3 | class B;
Attempt 2: Forward declare in new module
B_decl.mpp
export module B_decl;
export class B;
A.mpp
export module A;
import B_decl;
export class A {
public:
void f(B& b);
};
B.mpp
export module B;
import B_decl;
class B {};
A.mpp
module A;
import B;
void A::f(B& b)
{
// do stuff with b
}
When doing this, gcc errors with
B.mpp:5:14: error: cannot declare ‘class B@B_decl’ in a different module
5 | class B {};
| ^
In module B_decl, imported at B.mpp:3:
B_decl.mpp:3:14: note: declared here
3 | export class B;
Attempt 3: Forward declare in header, define in module
B_decl.h
class B;
A.mpp
module;
#include "B_decl.h"
export module A;
export class A {
public:
void f(B& b);
};
B.mpp
module;
#include "B_decl.h"
export module B;
class B {};
A.cpp
module A;
import B;
void A::f(B& b)
{
// do stuff with b
}
When doing this, gcc errors with
B.mpp:7:7: error: cannot declare ‘class B’ in a different module
7 | class B {};
| ^
In file included from B.mpp:3:
B_decl.h:1:7: note: declared here
1 | class B;
In Objective-C, classes and protocols can be forward-declared if you only need to use them as part of an object pointer type, e.g. MyClass * or id<MyProtocol>.
You cannot forward declare a nested structure outside the container. You can only forward declare it within the container.
A forward declaration is much faster to parse than a whole header file that itself may include even more header files. Also, if you change something in the header file for class B, everything including that header will have to be recompiled.
A forward declaration allows us to tell the compiler about the existence of an identifier before actually defining the identifier. In the case of functions, this allows us to tell the compiler about the existence of a function before we define the function's body.
The solution for this depends on why you want to forward declare in the first place.
If you are doing that to break a circular dependency, then usually the solution is to simply put them in the same module. Since the components are so tightly coupled together, it make sense to have them in the same module.
If you're doing that to make compilation faster, you're better to simply import the module and use the type. Importing a module has almost no cost. Compiling the module has, and it's only done one time.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With