Don't put definitions in header files, just declarations. Declarations specify that something exists while definitions actually define them (by allocating space). For example typedef
, extern
and function prototypes are all declarations, while things like struct
, int
and function bodies are definitions.
What's happening is that you're most likely including stdafx.h in multiple compilation units (C++ source files) and each of the resulting object files is getting its own copy of allocList
.
Then when you link the objects together, there's two (or more) things called allocList
, hence the link error.
You would be better off declaring the variable:
extern AllocList *allocList;
in your header file and defining it somewhere in a C++ source file (such as a main.cpp
):
AllocList *allocList;
That way, every compilation unit that includes stdafx.h
will know about the external variable, but it's only defined in one compilation unit.
Based on your further information:
I was trying to follow http://www.flipcode.com/archives/How_To_Find_Memory_Leaks.shtml, I assume that all those code are meant to be placed in the stdafx.h. Any other alternatives, pax?
My response is as follows.
I wouldn't put them in stdafx.h
myself since I think that uses some MS magic for pre-compiled headers.
Make a separate header file mymemory.h
and put your function prototypes in it, for example (note that this has no body):
inline void * __cdecl operator new(
unsigned int size,
const char *file,
int line);
Also in that header, put the other prototypes for AddTrack()
, DumpUnfreed()
, etc., and the #define
, typedef
and extern
statements:
extern AllocList *allocList;
Then, in a new file mymemory.cpp
(which also contains #include "mymemory.h"
), put the actual definition of allocList
along with all the real functions (not just the prototypes) and add that file to your project.
Then, #include "mymemory.h"
in every source file in which you need to track memory (probably all of them). Because there are no definitions in the header file, you won't get duplicates during the link and because the declarations are there, you won't get undefined references either.
Keep in mind that this won't track memory leaks in code that you don't compile (e.g., third-party libraries) but it should let you know about your own problems.