Functions defined in header / cpp file behaves different

Linux and Unix-Like Emergency UNIX and Linux Support
1

File: A.h

class A
{
  public:
  struct x X;
  int show()
  {
    x.member_variable ? 0: -1;
  }
};

Now if A.cpp is complied which includes A.h (which is actually in a huge project space) we see that x.member_variable value is not as expected. But if remove the show() method and place it in A.cpp the code behaves fine - meaning that x.member_variable value is correct.

How such a thing may happen - one thing we saw from objdump is that if the function is defined in A.h the the method is treated as inline function which otherwise is not if defined in A.cpp?

How the code can behave differently altogether?

2

This is not a good example of your problem, as the code cannot even compile(incomplete type errors). Even if it did, you never set the variable to anything hence cannot expect it to be any particular value. Could you post the relevant section of actual code?

3

The sample code is a snippet. Assume the compilation issue is resolved (x.member_variable is changed to 'return X.member_variable? 0 : -1' - which I believe is not the point I am trying to stress here). The issue is if we are having a similar type functionality in our feature (show method when defined in header file we see that value of X.member_variable is non-zero) but if we remove and keep the same code in A.cpp the value of x.member_varaible is 0. Please note that the flow is same. However objdump notifies us that show() method is promoted as inline function when within header file

4

Maybe you're actually including a different A.h than you think you are. That's what this smells like.

If you want to get to the bottom of this, make the smallest code you can that recreates your problem. Make a B.h that only contains the snippet above and a B.cpp that uses it and does nothing else. Does the problem still happen? What if you try using B.h from inside A.cpp (complex cpp, simple .h)? What about if you use A.h from inside B.cpp (simple cpp, complex .h)? What if you take A.h and cut it in 1/2,1/4,1/8 etc... (A1.h,A2.h include in B.cpp (1/2 complex .h file, simple .cpp file).

5

Thanks for pointing that.

OK we found out a way that the above issue could be possible code wise. Its the hierarchy of how we are linking our binary is the issue. Let me explain the situation - we have one header file that is conditionally compiled with #ifndef .. #define .. #endif kept in different directory. Now this header files gets archived into lib1.a lib2.a and so on. Hence when we link our library and if incase we required it from lib3.a during linking we need to make sure that it linked the first:

ldd .. lib1.a lib2.a lib3.a -- so the exact header does not gets linked properly. Note that all .a have some additional interfaces compiled and linked.

Its unfortunate is that the required header contains common declaration (defines same methods but are little bit different)

How can we resolve the issue? Including Namespace would mean a lot of revamp in our codebase? Is there a better way to do that?

What would be best design for such a code base - so that later onwards no developer can accidentally include these fatal signatures?

Please help