ansaurus

Question

Answer 1

+9 A:

By using "header guards":

#ifndef MYCLASS_H
#define MYCLASS_H

// MyClass.h
#pragma once

#include <winsock2.h>

class MyClass
{

// methods
public:
    MyClass(unsigned short port);
    virtual ~MyClass(void);
};

#endif

DevSolar 2009-09-03 09:55:13

I guess I am wrong (4 upvotes by now), but I think using include guards is the same as pragma once, you put them both?

Svetlozar Angelov 2009-09-03 10:06:30

Well, I have #pragma once which afaik is the same header guards

hab 2009-09-03 10:07:01

@Angelov: Yes, that's what I'm saying they are the same things. The problem is not with my header files, but I think <winsock2.h> itself doesn't have header guards or may be something else.

hab 2009-09-03 10:08:12

@Manzoor: What is the problem your trying address then?

Naveen 2009-09-03 10:08:22

The problem is that I include <winsock2.h> in my header and then in another header I include my previous header file and so comes the redefinition of WinSock2 structures. Why?

hab 2009-09-03 10:12:59

`#ifndef/#defined` include guards are fully portable standard c++. The behaviour of `#pragma once` is implementation dependent although many implementations make it behave exactly as include guards would.

Charles Bailey 2009-09-03 10:14:45

#pragma once relies on compiler, it's not the same as header guard, which is more portable

Fu4ny 2009-09-03 10:27:25

By definition #pragma is compiler dependent (non-standard). It may not work on all compilers. I know that visual studio accepts #pargma once. I'm not sure if gcc does. I know that include guards ALWAYS work. I use both #pragma once and include guards for maximum protability. It seems that MSVC has optimized handling of #pragma once and gcc has optimized handling of include guards. The only difference with my standard header is that #praga once is outside the include guards.

KitsuneYMG 2009-09-03 10:49:10

The '#pragma' command is specified in the ANSI standard to have an arbitrary implementation-defined effect. In the GNU C preprocessor, '#pragma' first attempts to run the game 'rogue'; if that fails, it tries to run the game 'hack'; if that fails, it tries to run GNU Emacs displaying the Tower of Hanoi; if that fails, it reports a fatal error. In any case, preprocessing does not continue.-- Richard M. Stallman, The GNU C Preprocessor, version 1.34

DevSolar 2009-09-03 10:51:02

Above comment posted to stress that #pragma does "something", while #ifndef / #define / #endif is fully portable, standard compliant, and recommended practice. @ Manzoor Ahmed: Try to boil down your problem to the minimum amount of code required to reproduce it. It's a very useful practice for debugging such problems.

DevSolar 2009-09-03 10:52:50

@ Svetlozar Angelov: I retained the #pragma once from the original code, not being 100% sure what it does, and simply wrapped the whole thing. Shouldn't hurt either way.

DevSolar 2009-09-03 10:54:05

Yea, but none of the solutions solved the problem

hab 2009-09-03 11:17:58

Then your problem is not related to multiple inclusions of MyClass.h. Again: Make a copy of your code, then methodically cut away files and source lines not necessary to reproduce the error, until you see the problem. Trust me, works every time.

DevSolar 2009-09-03 11:21:46

Thanks, I'll try myself.

hab 2009-09-03 11:32:44

pragma one is known to be faster than header guard, but it's not standard. So sometimes developer use both of them.

Fu4ny 2009-09-03 11:33:32

If "faster" really does matter to you, you can "header-guard" the #include statement (in the including source). That way the compiler doesn't even have to open the header file the second time around.

DevSolar 2009-09-03 11:51:12

@DevSolar: you're way out of date. GCC has supported #pragma once for years.

Steve Jessop 2009-09-03 12:46:45

@onebyone: That Richard Stallman quote was *humor*. You know? Like when you tell people that relying on undefined behaviour might format their hard drives...

DevSolar 2009-09-03 12:55:38

I know, but the questioner isn't relying on undefined behaviour, and Stallman's quote is not applicable. He's relying on defined behaviour of his compiler (just not defined in the C++ standard). So #pragma doesn't do "something", it does exactly what it says in MS's documentation. Accuse me of humourlessness, I'll accuse you of derailing the conversation, someone can chip in with a Nazi analogy, and we'll have the usenet trifecta ;-)

Steve Jessop 2009-09-03 13:47:52

Hrr, hrr... I'm game. :-D You might want to note, though, that the original, unedited post I was referring to did *not* state the compiler being used...

DevSolar 2009-09-03 14:13:46

Yeah, true. I'm now planning a filter for SO that looks at code snippets in questions, identifies compiler-specific code, and forces the questioner to specify compiler if there is any. Detecting code that relies on 2's complement arithmetic could be tricky, though...

Steve Jessop 2009-09-03 14:29:30

Answer 2

+2 A:

You should use header guard.

put those line at the top of the header file

#ifndef PATH_FILENAME_H
#define PATH_FILENAME_H

and at the bottom

#endif

Fu4ny 2009-09-03 09:58:46

#pragma once and include guards are same things aren't they?

hab 2009-09-03 10:05:54

They are not quite the same - the header guards will prevent re-inclusion of the file at the preprocessor level, plus they're obviously a tad more portable than #pragma once.

Timo Geusch 2009-09-03 10:14:23

I meant they are built for the same purposes :)

hab 2009-09-03 10:17:48

#pragma once is non-standard, afaik

Fu4ny 2009-09-03 10:22:36

Answer 3

+3 A:

#pragma once is flakey, even on MS compilers, and is not supported by many other compilers. As many other people have mentioned, using include guards is the way to go. Don't use #pragma once at all - it'll make your life much easier.

Thomi 2009-09-03 10:36:00

Unfortunately, I've seen more than zero botched include guards, either where a typo means the guard doesn't actually work, or where files of the same name in different directories use the same token, or where the token used begins with a double underscore or underscore then capital-letter (and hence is non-portable just like #pragma once). So for inherently non-portable code, like anything using winsock.h, I was deeply untroubled by #pragma once right up to the point you said it was flakey. When does it fail, other than not being supported at all?

Steve Jessop 2009-09-03 14:34:52

When using `#pragma once`, the compiler takes the header file node name as the unique Id. This can fail if you have symbolic links or NTFS junctions in your source tree (more common than you might think), or even if you have a file of the same name in another system include directory (this has happened to me before when I has version 1 and version 2 of the same library installed to two different system include paths).Bottom line: for me, I prefer to have more control, and live with the occasional wetware mistake, rather than trust a compiler to do it for me.

Thomi 2009-09-03 15:12:53

Answer 4

+2 A:

#pragma once is based on the full path of the filename. So what you likely have is there are two identical copies of either MyClass.h or Winsock2.h in different directories.

soru 2009-09-03 10:37:56

a symbolic link or NTFS junction will also cause the system to break.

Thomi 2009-09-03 13:40:04

Answer 5

+1 A:

#include guards are the standard way of doing this. #pragma once is not, meaning that not all compilers support it.

Dima 2009-09-03 10:45:54

Answer 6

+9 A:

This problem is caused when including <windows.h> before <winsock2.h>. Try arrange your include list that <windows.h> is included after <winsock2.h> or define _WINSOCKAPI_ first:

#define _WINSOCKAPI_    // stops windows.h including winsock.h
#include <windows.h>
// ...
#include "MyClass.h"    // Which includes <winsock2.h>

ansaurus

tags:

views:

answers:

C++ Redefinition Header Files

related questions