Thread: Headers, header guards, pre-compiled headers and globals

Originally Posted by jim_0

Now this all worked until I needed a global string

For a global variable, you should declare it as extern in a header file, then define it in exactly one source file.

However, are you sure you need this string to be global? Is it a constant? If it is modifiable, then could you perhaps declare it say, in the main function and then pass it around (by reference)?

Originally Posted by jim_0

By rule do you always put header guards in all .h files?

Yes, I use header guards in all my header files.

Originally Posted by jim_0

Parser.cpp has quite a few functions and Formatter.h has just stdafx.h.

Header files should not include the pre-compiled header. That is what each source file should do as the first header it includes.

Now I initially had this in Formatter.cpp which has

Code:

int main(){}

and passed this string to a function in Parser.cpp. This gives me a linking error, something like already referenced in Formatter.obj.

Sounds like you put globals in headers or included .cpp files. You should not do that.
Declare globals in one source file (and exactly one) and declare it as extern in a header. Declaring something extern is just a way to tell the compiler the variable exists and not to create it.

By rule do you always put header guards in all .h files?

Yes! Though, I tend to favour #pragma once. Always use include guards or #pragma once.

And can you not just put all your prototype declarations in one .h files and then include all .h files in stdafx.h?

Putting all declarations in one header goes against organization.

And how about globals again why can't you just put everything in one header and have that header in stdafx.h?

Because that headers gets included in all source files, which means that all of a sudden you have multiple global variables with the same name which leads to a linker error.

Generally, precompiled headers are good because they speed up compilation. However, beware that they can also slow down compilation. Since the precompiled header contains many headers, there is a lot of data to parse. So every time any of the headers that are included in the PCH are changed, the PCH needs to be recompiled, which in turn causes all source files to be recompiled. Very expensive.
So beware. Only put headers that are unlikely to change inside the PCH (e.g. system headers).

Originally Posted by Elysia

Declare globals in one source file (and exactly one) and declare it as extern in a header.

Just to be clear (I know you know this Elysia) the declaration in a source file is a definition (i.e. it actually creates the variable, corresponding to the extern declarations in header files).

Originally Posted by Elysia

Yes! Though, I tend to favour #pragma once. Always use include guards or #pragma once.

On this point, I disagree. #pragma once is not guaranteed to meet the requirement (by definition, as pragmas are compiler specific hooks, and the standard specifies no pragmas) and an #include guard will always work (if care is taken to ensure the guarding macro name is unique in a project). I would always use #include guards, unless I have a particular reason not to (which is rare), and never use #pragma once.

Some compilers (or, more accurately, preprocessors) have special handling of #include guards to speed up compilation but, even if that isn't so, #include guards are a technique that will work. #pragma once is a technique that will often (not always) work.

Originally Posted by Elysia

Generally, precompiled headers are good because they speed up compilation. However, beware that they can also slow down compilation. Since the precompiled header contains many headers, there is a lot of data to parse. So every time any of the headers that are included in the PCH are changed, the PCH needs to be recompiled, which in turn causes all source files to be recompiled. Very expensive.
So beware. Only put headers that are unlikely to change inside the PCH (e.g. system headers).

Personally, I turn off precompiled headers completely, unless the project is VERY small. Too many compilers that implement precompiled headers can still get confused (for example, if a header file gets changed, the precompiled header does not get rebuilt, so the affected source files are not recompiled at all). Tracking down bugs that result (where, for example, one source file is effectively compiled with a superseded header, and one is not, but the objects are linked together to form an executable) is hideously difficult.

Originally Posted by grumpy

On this point, I disagree. #pragma once is not guaranteed to meet the requirement (by definition, as pragmas are compiler specific hooks, and the standard specifies no pragmas) and an #include guard will always work (if care is taken to ensure the guarding macro name is unique in a project). I would always use #include guards, unless I have a particular reason not to (which is rare), and never use #pragma once.

Some compilers (or, more accurately, preprocessors) have special handling of #include guards to speed up compilation but, even if that isn't so, #include guards are a technique that will work. #pragma once is a technique that will often (not always) work.

Oh, I didn't say you should prefer #pragma once over include guards. Include guards are superior, but are also incredibly annoying to have to type out for every header file make unique.
#pragma once works with the popular compilers, so myself, I tend to use them since it's so much easier.

Personally, I turn off precompiled headers completely, unless the project is VERY small. Too many compilers that implement precompiled headers can still get confused (for example, if a header file gets changed, the precompiled header does not get rebuilt, so the affected source files are not recompiled at all). Tracking down bugs that result (where, for example, one source file is effectively compiled with a superseded header, and one is not, but the objects are linked together to form an executable) is hideously difficult.

You may have a point there, but usually compilers other than your popular PC compilers, tend to have quirks and other sources of frustration and bugs, so you're going to have to end up having to learn how to tame them anyway, so it's not like PCH not working properly might come as a surprise here... it's usually part of learning what the compiler can do and can't and how to fix it.
Presumably you meant very big or something? Very small doesn't make any sense.

Originally Posted by Elysia

Oh, I didn't say you should prefer #pragma once over include guards. Include guards are superior, but are also incredibly annoying to have to type out for every header file make unique.
#pragma once works with the popular compilers, so myself, I tend to use them since it's so much easier.

Okay. I must have read more than you intended in your previous post, when you said you favour pragma once.

Originally Posted by Elysia

You may have a point there, but usually compilers other than your popular PC compilers, tend to have quirks and other sources of frustration and bugs, so you're going to have to end up having to learn how to tame them anyway, so it's not like PCH not working properly might come as a surprise here... it's usually part of learning what the compiler can do and can't and how to fix it.

Sure. Not using precompiled headers is often part of "taming the compiler".

Originally Posted by Elysia

Presumably you meant very big or something? Very small doesn't make any sense.

Actually I did mean very small. Although my concept of "very small" (in rough terms, a development that takes 5 man years or less) exceeds what a lot of people would describe as large.

Size, like beauty, is in the eye of the beholder.

Originally Posted by grumpy

Sure. Not using precompiled headers is often part of "taming the compiler".

Sure, if they cause more problems than they're worth, it's worth turning them off
I just see finding out whether PCH are causing problems or not as part of the process of taming the compiler, not as a separate step.

Originally Posted by grumpy

Actually I did mean very small. Although my concept of "very small" (in rough terms, a development that takes 5 man years or less) exceeds what a lot of people would describe as large.

Size, like beauty, is in the eye of the beholder.

That sounds like a large project to me, though...
Although PCH often pays off in projects which are very big in terms of source files or have very long compilation times rather than the time to market, so I cannot really tell how "big" or "small" such a project as you describe is...

I am trying to get the Code::Blocks project to use PCH header correctly.

Some of the rules I found mainly by trial and error.

1. Do NOT include a PCH header inside another regular header.
2. Do include PCH header before any other includes in source files.
3. Do NOT have compiler pragmas like implementation or interface before the PCH header include.

Tim S.

Originally Posted by Elysia

That sounds like a large project to me, though...

The unit used is "man years", so once you start thinking in terms of a team of 10 to 20 people (team sizes that are achievable by maturing start-ups) it could feasibly be completed in half a year or less, upon which it does not sound so large any more.

But yeah, "size, like beauty, is in the eye of the beholder". I certainly would not call such a development "very small".

Originally Posted by Elysia

PCH often pays off in projects which are very big in terms of source files or have very long compilation times

Which is why I advocate against the use of precompiled headers by students: they are unlikely to see the benefits, but still may have to deal with the problems.

Originally Posted by laserlight

Which is why I advocate against the use of precompiled headers by students: they are unlikely to see the benefits, but still may have to deal with the problems.

*shrug*
Good learning experience. Plus, the only thing they have to do to experience long compilation times is to include Windows.h. Or boost.