Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 10 down vote favorite

New to C++! So I was reading this: http://www.learncpp.com/cpp-tutorial/110-a-first-look-at-the-preprocessor/

Header guards

Because header files can include other header files, it is possible to end up in the situation where a header file gets included multiple times.

So we make preprocessor directives to avoid this. But I'm not sure - why can't the compiler just... not import the same thing twice?

Given that header guards are optional (but apparently a good practice), it almost makes me think that there are scenarios when you do want to import something twice. Although I can't think of any such scenario at all. Any ideas?

share|improve this question
On the MS compiler there is #pragma once which tells the compiler to only include that file once. – CodesInChaos Mar 29 at 11:03

2 Answers

up vote 19 down vote accepted

They can, as shown by new languages that do.

But a design decision was made all those years ago (when the C compiler was multiple independent stages) and now to maintain compatibility the pre-processor has to act in a certain way to make sure old code compiles as expected.

As C++ inherits the way it processes header files from C it maintained the same techniques. We are supporting a old design decision. But changing the way it works is too risky lots of code could potentially break. So now we have to teach new users of the language how to use include guards.

There are a couple of tricks with header files were you deliberately include it multiple times (this does actually provide a useful feature). Though if we redesigned the paradigm from scratch we could make this the non-default way to include files.

share|improve this answer
up vote 3 down vote

It wouldn't be as expressive otherwise, given that they chose to maintain compatibility with C and thus keep on with a preprocessor rather than a traditional packing system.

One thing that comes to mind for me is I had a project that was an API. I had two header files x86lib.h and x86lib_internal.h. Because internal was huge, I segregated the "public" bits to x86lib.h so that users didn't have to set aside extra time for compiling.

This introduced a funny problem with dependencies though so I ended up having a flow that went like this in x86lib_internal

  1. Set INTERNAL preprocessor define
  2. Include x86lib.h (which was smart to act a certain way when internal was defined)
  3. Do some stuff and introduce some things used in x86lib.h
  4. Set AFTER preprocessor define
  5. Include x86lib.h again (this time it'd ignore everything except for a segregated AFTER portion which depended on elements of x86lib_internal

I wouldn't say it was the best way to go about it, but it achieved what I wanted.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.