Boost logo

Boost Users :

Subject: Re: [Boost-users] Library Developers Battling Cyclic Header Dependency
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2011-03-16 18:09:52


From: boost-users-bounces_at_[hidden] [mailto:boost-users-bounces_at_[hidden]] On Behalf Of Ryan

> The compiler is giving the error that it can't access the private members. Once the forward declaration is used the compiler can't seem to use the full class later.
 
class B;
 
class A {
 double x;
public:
 inline A(double x_):x(x_){}
 B inline convertToB(void);
};
 
class A;
 
class B {
 double y;
public:
 inline B(double y_):y(y_){}
 A inline convertToA(void);
};
 
B A::convertToB(void) {
 return B(x);
}
 
A B::convertToA(void) {
 return A(y);
}
 
int main() {return 0;}

Your problem was that you included A_detail before you defined class B. The above code compiles. Regardless of what files you put it in you have to include them in the right order or you will get errors. Include them in the order such as that functions that depend on both A and B are defined after both A and B are defined.
 
By the way, for functions defined in a header file without inline keyword the compiler has the option to inline them. Only if the compiler chooses not to inline the function will it caues a link error if there are multiple object files that contain that function definition. It is very easy to ship broken code that compiles and links because you are lucky and functions defined in header files without the inline keyword are inlined. If you specify the inline keyword the compiler still has the option not to actually inline them, but if it does so it makes them a weak symbol instead of a strong symbol, which allows the linker to choose any one of multiple possible duplicate weak symbol definitions of the same function in different object files, whereas a strong symbol will result in a duplicate function definition error.
 
Regards,
Luke


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net