Hi, I had a test program that set up ddraw, dinput and dsound (DirectX 7) and everything worked fine (everything was just in one .cpp file Now I have come to split each component (starting with dsound) out to their own .h and .cpp file, and I am getting linkage errors. In my original test program I had: #include {stdio.h} //pretend these are angled brackets #include {windows.h} #include {dinput.h} #include {ddraw.h} #include {windowsx.h} #include {mmsystem.h} #include {dsound.h} LPDIRECTSOUND pDSound; LPDIRECTSOUNDBUFFER lpdsbStatic; DSBUFFERDESC dsbdesc; MMCKINFO mmckinfoParent; MMCKINFO mmckinfoSubchunck; WAVEFORMATEX *pwfx; BYTE *sound; .... NOW I have created a MyDSound.h and MyDSound.cpp, the .h file contains: #ifndef MYDSOUND_H #define MYDSOUND_H #include {dsound.h} //pretend these are angled brackets #include {mmsystem.h} #include {windowsx.h} LPDIRECTSOUND pDSound; LPDIRECTSOUNDBUFFER lpdsbStatic; DSBUFFERDESC dsbdesc; MMCKINFO mmckinfoParent; MMCKINFO mmckinfoSubchunck; WAVEFORMATEX *pwfx; BYTE *sound; ..... and I have removed these includes and variables from the original singular .cpp file and have #included this header in the original singular .cpp file my new MyDSound.cpp also #includes this header and implements the functions declared in MyDSound.h Now when I compile I get a LNK2005 error for each of the 7 variables above, like so: MyDSound.obj : error LNK2005: "struct tWAVEFORMATEX * pwfx" (?pwfx@@3PAUtWAVEFORMATEX@@A) already defined in DrawInputSound.obj whats going on????? Edited by - gumball on 9/9/00 10:14:48 PM

Those structures/data variables are probably already defined in one of your other .h/.cpp files. Check them all out.

=======================================
A man with no head is still a man.
A head with no man is plain freaky.

Does your header file finish with

#endif

? This simply says "end of defining MYDSOUND_H.

Also make sure you include the libraries for DirectX dsound.lib I think.

The above mentioned errors are the most likely, and if not, there is simple the problem that you may have left something out, or duplicated it ... or most often, TWO or more files have the same #ifndef constant (a silly error arising from cut and paste ... but I''ve done it) ...

BUT ... there is also the posibility that the error is not in code at all ... in that case, it is simply that the precompiled header, and or make structure if fucked up. Here is the BEST solution for fixing these sorts of errors,

STEP ONE - perform a rebuild all, not a make or build.

STEP TWO - if and only if 1 did not fix problem, turn off precompiled header completely, and then perform another REBUILD ALL.

after looking at your error more closely, I suspect you will find my correction fixes the problem ... please post back when you solve it.


Good Luck.

I have done all of the above, the problem still remains....

try placing an extern in front of the variables in .h file, and putting the straight declerations in the .cpp file

Quantum nailed it right on ... i even had that problem when i''ve even had that problem before (almost 2 years ago though). if you # include a header in more than one compilation unit (in most cases this means .cpp files) than it cannot allocate any memory for any variables, because the linker will be unable to remove either of the multiple conflicting copies. Using the extern declaration in the header file, with the normal declaration in the cpp works, AND has the added benifit of letting you NOT put variables you don''t wish to share into the header file, and declare them as ''static'' in the cpp file (basically making them have unit only scope, not truely global).

hope that help clear things up.

Thanks all for your help,

however I am still confused as to the whys of all this.

I was under the impression that doing the #ifndef ... #define ... at the top of your header files stopped this multiple inclusion problem.

Also, if I have to extern these variables in the header and then declare them in the .cpp file, why dont I just put them straight in the .cpp file and not in the .h file at all? And if I do this, then it feels like I am defeating the purpose of header files.

(Although I am more familiar with C++, and putting class declarations in header files, and implementations in the .cpp files, which makes perfect sense to me)

you put the extern in the header, so stuff in other modules can access them