Заголовочные файлы переопределения C ++ (winsock2.h)

Эта проблема возникает при включении <windows.h> до <winsock2.h>. Попробуйте организовать свой список включения так, чтобы <windows.h> был включен после <winsock2.h>, или сначала определите _WINSOCKAPI_:

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

См. Также это .

Как предполагали другие, проблема заключается в том, что windows.h включен до WinSock2.h. Поскольку windows.h включает winsock.h. Вы не можете использовать одновременно WinSock2.h и winsock.h.

Решения:

• Включите WinSock2.h перед windows.h. В случае предварительно скомпилированных заголовков вы должны решить это там. В случае простого проекта это легко. Однако в больших проектах (особенно при написании переносимого кода без предварительно скомпилированных заголовков) это может быть очень сложно, потому что, когда ваш заголовок с WinSock2.h включен, windows.h уже может быть включен из другого файла заголовка / реализации.

• Определите WIN32_LEAN_AND_MEAN перед windows.h или в масштабе проекта. Но это исключит многие другие вещи, которые могут вам понадобиться, и вы должны включить их самостоятельно.

• Определите _WINSOCKAPI_ перед windows.h или в масштабе проекта. Но когда вы включаете WinSock2.h, вы получаете предупреждение о переопределении макроса.

• Используйте windows.h вместо WinSock2.h, если для вашего проекта достаточно winsock.h (в большинстве случаев это так). Это, вероятно, приведет к увеличению времени компиляции, но решит любые ошибки / предупреждения.

Эх - уродство винды ... Здесь важен порядок включения. Вам нужно включить winsock2.h перед windows.h. Поскольку windows.h, вероятно, включен из вашего предварительно скомпилированного заголовка (stdafx.h), вам нужно будет включить winsock2.h оттуда:

#include <winsock2.h>
#include <windows.h>

Используя «защиту заголовка»:

#ifndef MYCLASS_H
#define MYCLASS_H

// This is unnecessary, see comments.
//#pragma once

// MyClass.h

#include <winsock2.h>

class MyClass
{

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

#endif

Я столкнулся с этой проблемой, когда пытался вытащить сторонний пакет, который, по-видимому, включал windows.h где-то в его беспорядке заголовков. Определить _WINSOCKAPI_ на уровне проекта было намного проще (не говоря уже о более удобном для сопровождения), чем пробираться через их суп и исправлять проблемное включение.

Я проверил рекурсивные включения, я обнаружил файлы заголовков, которые включают (рекурсивно) некоторые #include "windows.h" и #include "Winsock.h" и написали #include "Winsock2.h". в эти файлы я добавил #include "Winsock2.h" в качестве первого включения.

Просто наберитесь терпения, просмотрите все по очереди и установите этот порядок, сначала #include "Winsock2.h", затем #include "windows.h".

В VS 2015 будет работать следующее:

#define _WINSOCKAPI_

В то время как следующее не будет:

#define WIN32_LEAN_AND_MEAN

Я нашел эту ссылку windows.h и winsock2.h, у которого есть альтернатива, которая отлично мне подошла:

#define _WINSOCKAPI_    // stops windows.h including winsock.h
#include <windows.h>
#include <winsock2.h>

У меня возникли проблемы с поиском места возникновения проблемы, но, добавив этот #define, я смог построить, не выясняя его.

Я бы не стал использовать только FILENAME_H, но

#ifndef FILENAME_H_AF06570D_B36E_4B82_8F97_C456AF4A38FD
#define FILENAME_H_AF06570D_B36E_4B82_8F97_C456AF4A38FD

//code stuff
#endif // FILENAME_H_AF06570D_B36E_4B82_8F97_C456AF4A38FD

Я всегда использовал postfix guid. Несколько лет назад я столкнулся с очень плохой базой кода, в которой были разные файлы заголовков с одним и тем же именем и включали защиту. В рассматриваемых файлах был определен класс с таким же именем. Если бы использовались только пространства имен. Некоторые проекты были скомпилированы, некоторые нет. Использование уникальных защитных элементов было частью решения, позволяющего различать заголовки и их содержимое.

В Windows с Visual Studio используйте guidgen.exe, в Linux - uuidgen -t.

Я столкнулся с той же проблемой, и вот что я обнаружил до сих пор:

Из этого выходного фрагмента -

c:\program files\microsoft sdks\windows\v6.0a\include\ws2def.h(91) : warning C4005: 'AF_IPX' : macro redefinition
c:\program files\microsoft sdks\windows\v6.0a\include\winsock.h(460) : see previous definition of 'AF_IPX'

-Похоже, что в ваше решение включены и ws2def.h, и winsock.h.

Если вы посмотрите на файл ws2def.h, он начинается со следующего комментария -

/*++

Copyright (c) Microsoft Corporation. All rights reserved.

Module Name:

    ws2def.h

Abstract:

    This file contains the core definitions for the Winsock2
    specification that can be used by both user-mode and 
    kernel mode modules.

    This file is included in WINSOCK2.H. User mode applications
    should include WINSOCK2.H rather than including this file
    directly. This file can not be included by a module that also
    includes WINSOCK.H.

Environment:

    user mode or kernel mode

--*/

Обратите внимание на последнюю строчку - «Этот файл не может быть включен модулем, который также включает WINSOCK.H»

Все еще пытаюсь исправить проблему, не внося изменений в код.

Дайте мне знать, если в этом есть смысл.

#pragma once основан на полном пути имени файла. Так что, скорее всего, у вас есть две идентичные копии MyClass.h или Winsock2.h в разных каталогах.

Вы должны использовать защиту жатки.

поместите эту строку в верхнюю часть файла заголовка

#ifndef PATH_FILENAME_H
#define PATH_FILENAME_H

и внизу

#endif

#pragma once нестабилен даже в компиляторах MS и не поддерживается многими другими компиляторами. Как уже упоминали многие другие люди, использование include guards - лучший вариант. Ни в коем случае не используйте #pragma once - это сделает вашу жизнь намного проще.

#include guards - стандартный способ сделать это. #pragma once - нет, то есть не все компиляторы его поддерживают.

В моем проекте (я использую VS 2008 SP1) работает следующее решение:

Заголовочный файл:

//myclass.h
#pragma once
#define _WINSOCKAPI_
#include <windows.h>

Cpp класс:

//myclass.cpp
#include "Util.h"
#include "winsock2class.h"
#pragma comment(lib, "Ws2_32.lib")

где #include "winsock2class.h" означает класс, в котором реализован winsock2.h:

//winsock2class.h
#include <winsock2.h>
#include <windows.h>
#pragma comment(lib, "Ws2_32.lib")

На самом деле я столкнулся с проблемой, когда мне пришлось определить winsock2.h как первое включение, похоже, у него есть другие проблемы с включениями из других пакетов. Надеюсь, это будет полезно для тех, кто сталкивается с той же проблемой, не только с windows.h, но и со всеми.