Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: .h Files and forward Declarations  (Read 24504 times)

0 Members and 2 Guests are viewing this topic.

Silvah

  • Guest
.h Files and forward Declarations
« Reply #30 on: February 22, 2011, 07:58:49 pm »
Quote from: "l0calh05t"

I said was. ;)
Of course you did. The point is that, well, it was but it is not anymore.

Quote from: "l0calh05t"

"#pragma" in and of itself is not an extension, but "#pragma once" is not part of any C or C++ standard.
Now you're right. :P

Quote from: "l0calh05t"
#pragma is specifically designed for compiler/os specific options and therefore non-portable.
In theory, yes. In practice, no. Vast majority of modern compilers do implement #pragma once. Compare that with export: a standard feature that is implemented by one or two compilers.

Quote from: "l0calh05t"
About mingw: The current version is ok with pragma once, although I did find a pragma once related bug in it's tracker (for the current version)
It'll be very kind of you if you post a link.

l0calh05t

  • Full Member
  • ***
  • Posts: 200
    • View Profile
.h Files and forward Declarations
« Reply #31 on: February 22, 2011, 08:06:34 pm »
Quote from: "Silvah"
Quote from: "l0calh05t"
About mingw: The current version is ok with pragma once, although I did find a pragma once related bug in it's tracker (for the current version)
It'll be very kind of you if you post a link.

Sure, here you go: http://permalink.gmane.org/gmane.comp.gnu.mingw.announce/2771 (tracker link is in the message)

Saboba42

  • Newbie
  • *
  • Posts: 8
    • View Profile
.h Files and forward Declarations
« Reply #32 on: February 23, 2011, 03:19:49 am »
So... could we please move the (now proven to not be a fix) #pragma once discussion to another thread please?  Thank you.

@DoctorJ

Quote
For the sake of testing, can you move or copy that "enum MakeEvent ..." into EventManager.h and confirm that everything would work if it could find it? Perhaps add a fake enum into GQE_Types.h and see if it that can be referenced somewhere else within EventManager.h?


Yes, I just did and it compiles completely fine if the enum statement is placed in EventManager.h inside the namespace GQE brackets.  This follows the original pattern - the compiler recognizes the included headers, but not the forward declarations.  However, if the forward declarations are made in the files they are used in, they work just fine.  Other header files that originally came with the source code can use declarations in the GQE/GQE_Types.h perfectly fine - it's just a few headers that I have added that can't find anything there.

Oh wow... just did more testing and the plot thickens.  There is another enum in the GQE_Types file that has been there since I got the original source code called StatusType.  When I replace "MakeEvent" with "StatusType" in EventManager.h, the program compiles normally.  However, when I use MakeEvent, the program will only compile if my new enum (MakeEvent) is declared in the EventManager.h header.

Summery: the enums and class declarations that came with GQE_Types are completely usable in all header files that GQE_Types is included in.  All of the class declarations and enums that I have added to the header will only work if I make the declaration in the header that I use them in (However, if I include EventManager.h in EventManager.cpp, then the .cpp file will use MakeEvent just fine - it just doesn't like my enums/forward declarations added to GQE_Types.h)

@devlin:
Quote
Did you intend to make it a const reference? (and thus forgot the &)

Also, namespaces shouldn't have a semicolon ';' after them. Usually this isn't much of an issue as it would be stripped out by the compiler as a noop - but I'm not sure how well C::B functions.


No, just meant to pass the MakeEvent to the function.  Thanks for the namespace tip.  I stripped out a few semi-colons from the namespace brackets and it didn't do anything good or bad.  I'm too lazy to go through and take them out, so they'll probably stay for a bit  :P

DoctorJ

  • Newbie
  • *
  • Posts: 21
    • View Profile
.h Files and forward Declarations
« Reply #33 on: February 24, 2011, 12:38:31 am »
try moving your "MakeEvent" enum to preceed the "StatusType" enum. (Just in case there is some mismatch of braces that errantly signal the end of the namespace.)

Saboba42

  • Newbie
  • *
  • Posts: 8
    • View Profile
.h Files and forward Declarations
« Reply #34 on: February 24, 2011, 06:03:17 pm »
Nope, problem remains :x .

<UPDATE> The problem is solved when I put the problem enums in their own header file.  For some reason, the compiler didn't recognize the enums in GQE_Types.h, but it is fine with them in their own header file.  I guess this solves my problem, but I would like to know what makes this happen for future reference</UPDATE>

It looks like the compiler is rebuilding everything when I change the GQE_Types.h file, but it just feels like the compiler is skipping over everything I add...  Anything that could cause it to see only the stuff that was in the file on the first compile?  Fixated on an out of date object file?  I cleared them all, though and got a fresh compile, so maybe that's out too.

DoctorJ

  • Newbie
  • *
  • Posts: 21
    • View Profile
.h Files and forward Declarations
« Reply #35 on: February 24, 2011, 06:53:36 pm »
This may sound silly, but double check that the current GQE_Types.h file is actually the one being used by CB for the project. CB will happily keep files in the editor without them being part of the project. I've been caught by that before - it may reference a file in a different directory with the same name but obviously, it doesn't get updated as you edit the file with the same name in another directory.

Saboba42

  • Newbie
  • *
  • Posts: 8
    • View Profile
.h Files and forward Declarations
« Reply #36 on: February 25, 2011, 01:33:41 am »
@doctorJ:
I think that's what was wrong.  I found another version of the file in another folder and moved it.  The whole project rebuilt and it all works now.  Thanks for your help (and not talking about #pragma once =P)