MFC projects cause "multiple definition" linker errors?

Question

Is there something special about how an MFC project handles includes?

Here's the scenario. I like to define my class member functions in the h file, instead of splitting up a class between two files.

In Visual Studio I can create an empty Win32 project and do something like this:

main.cpp:

#include "doubleDef.h"

int main()
{
    doubleDef t;
    t.func();
    return 0;
}

doubleDef.h:

#pragma once

class doubleDef
{
public:
   int func();
};

int doubleDef::func()
{
    return 4;
}

This builds just fine.

If I take doubleDef.h into an MFC dialog project, and add #include "doubleDef.h" to the h file of the main dialog, I get LNK2005, saying that func is already defined, making it seem as if the #pragma once is being ignored.

If I instead include doubleDef.h in the main dialog's cpp file, everything is fine. But in the empty Win32 I can include doubleDef.h "multiple times" by doing this:

Header.h

#pragma once
#include "doubleDef.h"

Header1.h

#pragma once
#include "doubleDef.h"

main.cpp:

#include "Header.h"
#include "Header1.h"

int main()
{
    doubleDef t;
    t.func();
    return 0;
}

That is, it appears #pragma once works as expected (prevents multiple definitions of doubleDef::func()).

If I turn doubleDef into a template class, then the function definition must be in the h file. Likewise, I can make func inline, either by adding the keyword or implicitly by defining it next to the declaration in the class (as in int func() {return 4;}), and then, again the definition must be in the h file.

According to the documentation, the compiler treats inline as more or less optional, so it seems like if I just want to keep everything in the h file, I can just make everything inline.

What gives?

My upvote for @MarkRansom's answer is for these two points: 1) The #pragma once means the file will only be included once per source file. If you have many source files including it, you will still get a copy in each source file. 2) The usual way of working is to have the declarations in the header file, and the definitions (implementation) in another source file" Regarding 2), you should checkout the answers here: http://stackoverflow.com/questions/1783849/what-are-the-advantages-and-disadvantages-of-implementing-classes-in-header-file — yasouser, Apr 21 '15 at 00:44
Neither answer addresses the fact that I've created an example where I'm including a function definition twice (if your descriptions of `#pragma once` are correct) and it compiles *and* links fine. The same thing in an MFC project fails. Moreover, template classes require the definitions to be in the `h` file and they don't have to be inline for everything to compile and link. — darda, Apr 23 '15 at 14:46
With regards to c++ template classes, if you have access to "C++ templates - The complete guide" (http://www.josuttis.com/tmplbook/tmplbook.html) book, please refer to Chapter 6. Using Templates in Practice. The whole chapter talks about it. — yasouser, Apr 23 '15 at 17:49

score 6 · Answer 1 · answered Apr 07 '15 at 16:59

6

The #pragma once means the file will only be included once per source file. If you have many source files including it, you will still get a copy in each source file.

By declaring a function inline, you tell the compiler it's OK to have multiple copies - as long as those copies are identical.

The usual way of working is to have the declarations in the header file, and the definitions (implementation) in another source file.

P.S. MFC has nothing to do with your problems.

answered Apr 07 '15 at 16:59

Mark Ransom

299,747
42
398
622

Please check my edit. I still thing MFC has some `#include` setup or project setting which is causing this linker error. – darda Apr 07 '15 at 17:21
@pelesl you didn't put the .h file into "Source Files" rather than "Header Files", did you? – Mark Ransom Apr 07 '15 at 18:36
In the actual case where I have these issues, I have custom "filters" in the project. But for these examples, `h` files are in "Header Files" and `cpp` in "Source Files". Honestly I am not getting anything out of your answer and I don't understand why people are up-voting it. – darda Apr 08 '15 at 17:40
and It doesn't seem that changing which filters files are in makes any difference. – darda Apr 08 '15 at 17:43
Would putting a traditional `#ifndef doubledef_h` guard do the trick, rather than relying on `#pragma once`? – Mike Ounsworth Apr 21 '15 at 15:46
@MikeOunsworth theoretically it shouldn't make a difference. If it does then that would definitely shed some light on the problem. – Mark Ransom Apr 21 '15 at 16:35
I don't agree with your `#pragma once`. The [documentation](https://msdn.microsoft.com/en-us/library/4141z1cx.aspx) says "This can reduce build times as the compiler will not open and read the file after the first #include of the module." To me, this means the file is read once and only once regardless of how many other files you include it in, and that's why my example where it is included twice does not cause a linker error. However, in MFC, this does not appear to work, so I think there's something special in MFC projects (like the demand that you include `sdtafx.h` in every cpp). – darda Apr 23 '15 at 14:49

Barmak Shemirani · Answer 2 · 2015-04-20T20:16:01.737

This was already answered before, here is more detailed explanation:

You cannot define a function more than once, unless it is inline

You cannot declare a function more than once in the same file.

You do need to declare functions and classes multiple times if they are referenced in multiple .cpp files.

#pragma once prevents multiple declarations in the same file. It will not prevent multiple declarations in different files. Multiple declarations is exactly what you want and it is why you are including the files in multiple .cpp files in the first place.

class N1 {
public:
    //Declaration 
    //Multiple .cpp files need to know about this class and its members
    int foo();
};

//Definition 
//should be done once. This should go to .cpp file
int N1::foo() {
    return 1;
}

In the above example, compile will work fine in multiple .cpp file. The compile routine does not notice multiple definitions. But the linker notices multiple definitions and complains. You have to move the definition to .cpp file or use inline functions.

class N2 
{
public:
    int foo(); 
};

inline int N2::foo() 
{ //valid, even if it is repeated in different files
    return 1;
}

class N3 
{
public:
    int foo() //always valid
    { 
        return 1;
    }
};

score 0 · Accepted Answer · answered Apr 26 '15 at 01:16

In your simple Win32 project you have one main file that keeps including the same item, basically a no-op. To have multiple of the same include in referenced in the same file does not create a new link.

However with your MFC project you put your header file into mainfrm.h. That file is included in several other files in that project not just the mainfrm.cpp. Essentially creating a new link for each of those other files the main header was included in.

1>MainFrm.obj : error LNK2005: "public: int __thiscall doubleDef::func(void)" (?func@doubleDef@@QAEHXZ) already defined in MfcTest.obj 1>FileView.obj : error LNK2005: "public: int __thiscall doubleDef::func(void)" (?func@doubleDef@@QAEHXZ) already defined in MfcTest.obj 1>ClassView.obj : error LNK2005: "public: int __thiscall doubleDef::func(void)" (?func@doubleDef@@QAEHXZ) already defined in MfcTest.obj 1>OutputWnd.obj : error LNK2005: "public: int __thiscall doubleDef::func(void)" (?func@doubleDef@@QAEHXZ) already defined in MfcTest.obj 1>PropertiesWnd.obj : error LNK2005: "public: int __thiscall doubleDef::func(void)" (?func@doubleDef@@QAEHXZ) already defined in MfcTest.obj

Take a look at that output. You can see each of the other components that thinks it has that object.

To put it another way your original statement of why does it work for one way and not the other is because the complexity of the second example (MFC) actually includes that header all over the place. If you only want it used by the main form then include it in the cpp for it.

Finally, this made sense. In MFC the dialog `h` file is included in two places, the application's `cpp` and the dialog's `cpp`. — darda, Apr 27 '15 at 14:07

MFC projects cause "multiple definition" linker errors?

3 Answers3