Difference between pragma once inside and outside include guards?

Question

Is there any difference between placing the #pragma once inside the include guards as opposed to outside?

case 1:

#ifndef SOME_HEADER_H
#define SOME_HEADER_H
#pragma once

case 2:

#pragma once
#ifndef SOME_HEADER_H
#define SOME_HEADER_H

I'm just wondering out of curiosity if there's any special cases where I should prefer one or the other (case 1 or case 2) since I've decided to combine both (pragma and header guards) in my code.

EDIT:

I think you guys are misinterpreting my question... I am asking about the location of pragma once, not pragma once -vs- header guards.

Answer 1

There's a subtle difference in that if SOME_HEADER_H is already defined before the header is included, then in the second case the preprocessor will process the #pragma once, and in the first case it won't.

You'll see a functional difference if you #undef SOME_HEADER_H and include the file again by the same TU:

#define SOME_HEADER_H
#include "some_header.h"
#undef SOME_HEADER_H
#include "some_header.h"

Now, in case 1 I have all the definitions from the header file. In case 2 I don't.

Even without the #undef, you could conceivably see a difference in preprocessing time due to the #pragma once being ignored in case 1. That's up to the implementation.

I can think of two plausible ways it could already be defined before the first inclusion of this header file:

• (the obvious one) a completely separate file defines it, either deliberately or by accidental name clash,
• a copy of this file has already defined it. Depending on implementation that might include the case where this file gets involved in the same TU under two different filenames, e.g. because of a symbolic link or filesystem merge. If your implementation supports #pragma once, and you examine its documentation very carefully, you may be able to find a definitive statement whether the optimization is applied by the path under which the file is included, or by comparison of something which identifies a file's storage, like inode number. If the latter, you may even be able to figure out whether there are still scams that could be pulled to trick the preprocessor, such as remote-mounting a local filesystem to conceal that it's "the same file really"...

Used in the expected way, though, there's no difference provided that the implementation treats #pragma once in the way that Microsoft defines it. As long as it's processed rather than skipped, it marks the containing file for the optimization, so it doesn't matter whether or not it would be processed on a second pass through the file -- the second pass won't happen.

And of course since the pragma is non-standard, at least in theory it could have a completely different meaning on different implementations, in which case it might matter when and how many times it is processed. In practice, you'd think nobody will do that.