Error C2731: 'WinMain' : function cannot be overloaded


I have some code, (most of which is made by others), that uses JUCE and compiled and linked fine in VS .NET 2005.

Now I’ve made some changes in the code, and now suddenly I get this error when compiling:

1>Main.cpp 1>c:\projects\eio\tcnear_tca_and_driver_supp_workingbranch\product\eio\controlpanel\private\source\main\main.cpp(14) : error C2731: 'WinMain' : function cannot be overloaded 1> c:\projects\eio\tcnear_tca_and_driver_supp_workingbranch\product\eio\controlpanel\private\source\main\main.cpp(14) : see declaration of 'WinMain'

Main.cpp looks like this:

// File: Main.cpp ©2005 TCWorks Soft- & Hardware GmbH
/** @file Main.cpp

@h 10, June 2005, (Matthias Muchaier) Initial version.

#include “Main.h”
#include “Application/ControlPanel.h”

// This macro creates the application’s main() function…

// File: Main.h ©2005 TCWorks Soft- & Hardware GmbH
/** @file Main.h
Declaration of class Main

@h 10, June 2005, (Matthias Muchaier) Initial version.

#include <windows.h>

#include “juce/TCGroup/TCJuce.h”

Neither Main.cpp nor Main.h has been changed since it compiled and linked OK.

I tried the suggestion from the other “WinMain problem” string:

but then I get a lot of other errors.

Does someone know, what usually is the problem, that causes the above error and/or what I could/can do to solve it ?

Thanks in advance

Just sounds like you’ve got a duplicate definition of it somewhere. First thing I’d try would be grepping all your code for “winmain”.

I’ve searched the whole solution (in VS 2005) and the whole dir tree and can’t find WinMain anywhere else than in juce.h:

... #else #define START_JUCE_APPLICATION(AppClass) \ int __stdcall WinMain (int, int, const char* commandLine, int) \ { \ String commandLineString (commandLine); \ return JUCEApplication::main (commandLineString, new AppClass()); \ } #endif

– Eigil

i had the same problem as you a year ago.
probably you’re including juce.h before some weird windows header files.
just include the win32 headers BEFORE juce.h or just use juce_WithoutMacros.h

It looks like the problem is solved by not including juce.h anywhere before windows.h (juce.h was included in the PreCompiled Headers e.g. and windows.h was not. Couldn’t include windows.h there though without errors, but removed juce.h)



I’m stumped at the moment by a similar problem that doesn’t seem to be solvable by simply moving headers around. I’m working on an application that uses Juce and MFC for communicating with an external camera.

When I put the include for the juce_WithoutMacros.h header at the top, I get the WinMain error:

error C2731: ‘WinMain’ : function cannot be overloaded

When I include the header file with the includes of the MFC headers, I get a ton of errors from the cmath library that look like:

error C2039: ‘acosf’ : is not a member of ‘global namespace'' error C2873: 'acosf' : symbol cannot be used in a using-declaration error C2039: 'asinf' : is not a member of 'global namespace’’
… and so on…

I’ve been working on this problem for a couple of days now, but nothing seems to work. Does anyone have any suggestions?


Ouch! Why on EARTH would you do that? One thing in my experience is that MFC doesn’t mix with ANYTHING. Almost not even itself. If you’re trying to go outside the MFC box, you nearly will have to break your back to do it. Isn’t there someway you can ditch MFC ?

When I get this kind of situation, e.g. when I was trying to do RTAS, it’s usually possible to use separate cpp files - i.e. you’d have one cpp that only includes juce and another that only includes MFC. Then you’d have some shared functions to do the necessary comms between them.

But I do have to agree with robiwan… Yeesh… MFC is one of my all-time least favourite things.

MFC is not one of my favorite things either, but there was no way around me using it, because the camera driver uses MFC classes…

Thanks for your tip, Jules. I did as you suggested, but unfortunately, I was still having linking errors. I finally found a solution to the problem though by following the advice in this article: Basically, it’s a trick to make certain MFC libraries load later in the linkage process to avoid conflicts with dual definitions of certain C++ standard functions.