Redefinition Errors on Build

[SimpleCoder]

Win10, MSVS 17.11.3, C++ latest, console app.

I'm a novice, hobbyist coder. I have a not-too-esoteric console app that contains a file for the main() function, 3 traditional compilation units (.cpp/.hpp) and 3 modules (.ixx/.cpp), each describing one class. The main file is essentially a test bench for the other classes so it has #includes for the headers, imports for the modules, and way too much code for helper apps supporting a simple console menu system. I import std.core for the STL.

It builds and runs successfully.

I wanted a cleaner main() so I moved the supporting functions to their own .cpp/.hpp, creating an WxApp class to handle all of the necessary instantiations. I created a new GitHub branch for this conversion so I haven't lost anything except my time :-).

This left the main entry as:

#include "WxApp.hpp"								

int main()
{
	WxApp wxApp;
	auto initialized = wxApp.init();

	if (!initialized)
	{
		wxApp.GetLog()->LogError("WxApp::init() failed.  Terminating.");
		return 1;
	}

	wxApp.GetLog()->LogInfo("WxApp::init() successful.");
	std::shared_ptr<Log> wxLog{ wxApp.GetLog() };																

	wxApp.run();


	wxLog->LogInfo("WxGenerator shutting down.");

	return 0;
}

And the WxApp class header as:

#pragma once

#pragma warning(disable:5050)
import std.core;

import WxRandom;
import Log;
import VersionData;
#include "WxMonth.hpp"
#include "WxTableData.hpp"
#include "WxWatch.hpp"

#include <optional>
#include <Windows.h>
#include <winver.h>

using std::string;
using std::shared_ptr;

class WxApp
{
public:
	WxApp();
	~WxApp();

	bool init();
	void run();
	//bool startUp(shared_ptr<Log>);
	std::unique_ptr<Log> GetLog();
	/*WxTableData* GetTableData();
	WxRandom* GetRandom();
	WxMonth* GetMonth();
	WxWatch* GetWatch();*/
private:
	static void mainMenu(shared_ptr<Log>, WxTableData&);
	static void maintMenu(shared_ptr<Log>, WxTableData&, WxRandom&, const string&);
	static void inspectMenu(shared_ptr<Log>, WxWatch&, const WxTableData&, const string&);
	static void monthMenu(shared_ptr<Log>, WxMonth&, WxTableData&, const string&);
	static void watchMenu(shared_ptr<Log>, WxWatch&, WxTableData&, const string&);

	std::optional<VersionData> GetVersion(const string&, std::shared_ptr<Log>);
	string GetErrorMessage(const DWORD);

	Log* mLog{ nullptr };
	shared_ptr<WxTableData> mTableData{ nullptr };
	shared_ptr<WxRandom> mRandom{ nullptr };
	shared_ptr<WxMonth> mMonth{ nullptr };
	shared_ptr<WxWatch> mWatch{ nullptr };
	int mYear;
};

The only include in WxApp.cpp is #include "WxApp.hpp" but it's 1k lines long so I'm not posting it here. All of the individual .cpp and modules compile correctly and w/o error, except for the WxApp class which generates 31 errors of the types "type redefinition" (C2011), "function already has a body" (C2084), "class template already defined" (C2953), all associated with Windows headers: xtr1common, vcruntime_new.h, and yvals.h.

Consequently, building the project generates 62 errors of the same types and in the same files.

Any advice in how to track down the source of these errors or what the heck I'm doing wrong?

Oh, and BTW, how do I change the formating of the text, particularly the code format? The buttons below the edit window do not respond. Figured it out. I'll have to use the tags and not the button when originallly writing the question.

[jonnin]

its late, but at a glance...
templates must be header only, no cpp file. Any chance your cleanup split up a template by mistake? The errors you give may indicate that issue.

post the exact errors, word for word, if its not the above.

[SimpleCoder]

I have no user-defined templates in any compilation unit.

When attempting to compile the WxApp class, I get the following errors (output from MSVS's error window). The Path field is always

D:\Programs\Visual Studio 2022\VC\Tools\MSVC\14.41.34120\include

, so I've removed several columns (such as line number) for clarity and brevity. Sorry for the poor formatting:

Error	C2011	'std::nothrow_t': 'struct' type redefinition	D:\Programs\Visual Studio 2022\VC\Tools\MSVC\14.41.34120\include\vcruntime_new.h
Error	C2011	'std::align_val_t': 'unsigned enum' type redefinition	D:\Programs\Visual Studio 2022\VC\Tools\MSVC\14.41.34120\include\vcruntime_new.h
Error	C2084	function 'void *operator new(size_t,void *) noexcept' already has a body	D:\Programs\Visual Studio 2022\VC\Tools\MSVC\14.41.34120\include\vcruntime_new.h
Error	C3615	constexpr function 'operator new' cannot result in a constant expression	D:\Programs\Visual Studio 2022\VC\Tools\MSVC\14.41.34120\include\vcruntime_new.h
Error	C2953	'std::integral_constant': class template has already been defined	D:\Programs\Visual Studio 2022\VC\Tools\MSVC\14.41.34120\include\xtr1common
Error	C2955	'std::integral_constant': use of class template requires template argument list	D:\Programs\Visual Studio 2022\VC\Tools\MSVC\14.41.34120\include\xtr1common
Error	C2386	'bool_constant': a symbol with this name already exists in the current scope	D:\Programs\Visual Studio 2022\VC\Tools\MSVC\14.41.34120\include\xtr1common
Warning	C4348	'std::enable_if': redefinition of default parameter: parameter 2	D:\Programs\Visual Studio 2022\VC\Tools\MSVC\14.41.34120\include\xtr1common
Error	C2953	'std::enable_if': class template has already been defined	D:\Programs\Visual Studio 2022\VC\Tools\MSVC\14.41.34120\include\xtr1common
Error	C3855	'std::enable_if': template parameter '_Ty' is incompatible with the declaration '_Test'	D:\Programs\Visual Studio 2022\VC\Tools\MSVC\14.41.34120\include\xtr1common
Error	C2976	'std::enable_if': too few template arguments	D:\Programs\Visual Studio 2022\VC\Tools\MSVC\14.41.34120\include\xtr1common
Error	C2386	'enable_if_t': a symbol with this name already exists in the current scope	D:\Programs\Visual Studio 2022\VC\Tools\MSVC\14.41.34120\include\xtr1common
Error	C2953	'std::conditional': class template has already been defined	D:\Programs\Visual Studio 2022\VC\Tools\MSVC\14.41.34120\include\xtr1common
Error	C3855	'std::conditional': template parameter '_Ty1' is incompatible with the declaration '_Test'	D:\Programs\Visual Studio 2022\VC\Tools\MSVC\14.41.34120\include\xtr1common
Error	C2976	'std::conditional': too few template arguments	D:\Programs\Visual Studio 2022\VC\Tools\MSVC\14.41.34120\include\xtr1common
Error	C2386	'conditional_t': a symbol with this name already exists in the current scope	D:\Programs\Visual Studio 2022\VC\Tools\MSVC\14.41.34120\include\xtr1common
Error	C2953	'std::is_same': class template has already been defined	D:\Programs\Visual Studio 2022\VC\Tools\MSVC\14.41.34120\include\xtr1common
Error	C2953	'std::remove_const': class template has already been defined	D:\Programs\Visual Studio 2022\VC\Tools\MSVC\14.41.34120\include\xtr1common
Error	C2953	'std::remove_const': class template has already been defined	D:\Programs\Visual Studio 2022\VC\Tools\MSVC\14.41.34120\include\xtr1common
Error	C2386	'remove_const_t': a symbol with this name already exists in the current scope	D:\Programs\Visual Studio 2022\VC\Tools\MSVC\14.41.34120\include\xtr1common
Error	C2953	'std::remove_cv': class template has already been defined	D:\Programs\Visual Studio 2022\VC\Tools\MSVC\14.41.34120\include\xtr1common
Error	C2953	'std::remove_cv': class template has already been defined	D:\Programs\Visual Studio 2022\VC\Tools\MSVC\14.41.34120\include\xtr1common
Error	C2953	'std::remove_cv': class template has already been defined	D:\Programs\Visual Studio 2022\VC\Tools\MSVC\14.41.34120\include\xtr1common
Error	C2953	'std::remove_cv': class template has already been defined	D:\Programs\Visual Studio 2022\VC\Tools\MSVC\14.41.34120\include\xtr1common
Error	C2386	'remove_cv_t': a symbol with this name already exists in the current scope	D:\Programs\Visual Studio 2022\VC\Tools\MSVC\14.41.34120\include\xtr1common
Error	C2953	'std::_Disjunction': class template has already been defined	D:\Programs\Visual Studio 2022\VC\Tools\MSVC\14.41.34120\include\xtr1common
Error	C3855	'std::_Disjunction': template parameter '_False' is incompatible with the declaration '_First_value'	D:\Programs\Visual Studio 2022\VC\Tools\MSVC\14.41.34120\include\xtr1common
Error	C2953	'std::disjunction<_First,_Rest...>': class template has already been defined	D:\Programs\Visual Studio 2022\VC\Tools\MSVC\14.41.34120\include\xtr1common
Error	C2084	function 'bool std::is_constant_evaluated(void) noexcept' already has a body	D:\Programs\Visual Studio 2022\VC\Tools\MSVC\14.41.34120\include\xtr1common
Error	C3615	constexpr function 'std::is_constant_evaluated' cannot result in a constant expression	D:\Programs\Visual Studio 2022\VC\Tools\MSVC\14.41.34120\include\xtr1common
Error	C1116	unrecoverable error importing module 'std.filesystem'.  Specialization of 'std::bool_constant' with arguments 'std::is_integral_v<_Ty>'	D:\Programs\Visual Studio 2022\VC\Tools\MSVC\14.41.34120\include\xtr1common
Error	C2011	'std::_Uninitialized': 'enum' type redefinition	D:\Programs\Visual Studio 2022\VC\Tools\MSVC\14.41.34120\include\yvals.h

I'm sure that I'm duplicating some include, somewhere, but can't trace it to a particular file other than WxApp.cpp/.hpp. I successfully compile every other unit.

[jonnin]

that actually looks like a project settings problem, but I am not sure what exactly to tell you to do to fix it...
if I had to guess, you may be somehow mixing 32 and 64 bit libraries, and/or because of that, possibly including 2 copies. But this is just a guess, I am still trying to run it down with what you have given...

[Duthomhas]

Those are compilation errors, not linker errors. I think that there is a .cpp file being #included somewhere.

[Ganado]

except for the WxApp class which generates 31 errors of the types "type redefinition

If it's a compilation error, that would mean it is a compilation unit that's failing, and not the header file itself. Which compilation unit (usually a compiled .cpp file) is not building correctly? Start there.

Are you positive you have #include guards, or #pragma once, since basically all compilers support it, in all of your custom header files?

Also is this project related to wxWidgets, or is that just a coincidence?

[seeplus]

Do any of the .hpp include files have #include for std files that are already imported by import std.core?

[Peter87]

The errors seem to be coming from within a MS header so maybe its a bug with their module support.
Possibly related to this: https://github.com/microsoft/STL/issues/4666

[SimpleCoder]

Thanks, all, for the suggstions.

@jonnin

if I had to guess, you may be somehow mixing 32 and 64 bit libraries, and/or because of that, possibly including 2 copies. But this is just a guess, I am still trying to run it down with what you have given...

I'll check WxApp for this since it's the only one generating errors and the latest addition to the project.

@Duthomhas

Those are compilation errors, not linker errors. I think that there is a .cpp file being #included somewhere.

Agreed. I'll review all the compilation units again for this but at this point I'm not entirely sure what I'm looking for. I understand there's a tool (depends.exe??) that might be of some help.

@Gandado

Which compilation unit (usually a compiled .cpp file) is not building correctly?

WxApp and consequently the file with main() in it. When I compile WxApp I get 31 errors. When I compile the project I get 62 errors. Coincidence?

@seeplus

Do any of the .hpp include files have #include for std files that are already imported by import std.core?

Good question. I've tried to reduce the necessary imports and found that I need to import std.core and std.filesystem, but I believe that's expected.

I have noticed that the errors only begin when I #include <Windows.h> (for the definition of DWORD, and who knows what else) and <winver.h>, both needed for my code that recovers version information from a .rc file in my VersionData module, which I import in WxApp only (see the WxApp.hpp file in the OP).

I've removed an #include <cstdint> in WxMonth.hpp as unnecessary but no improvement.

@Peter87

a bug with their module support

Entirely likely. I had originally tried WxApp as a module but it failed the same way so I thought if I reverted to a traditional header approach, it'd be good. I guess not.

[SimpleCoder]

Hypothetically, if, in file#1, I import module#1 that itself imports std.core or std.filesystem, why should I have to re-import those modules in file#1?

[seeplus]

What import/include are in the .hpp files?

[SimpleCoder]

I have reduced WxApp to the bare minimum and I can almost get it to compile. I have commented out all function declarations and definitions except for the Log function. I also added using std::unique_ptr; since I was struggling with adding #include <memory> and additional "duplicate definition" errors. Apparently memory.h is include in std.core. Most notably, I've removed references to <Windows.h> and <winver.h>.

I figure this is a good place to start building up the functionality.

The only compile error I'm getting is C2280 on line 38 of WxApp.cpp:

std::unique_ptr<Log,std::default_delete<Log>>::unique_ptr(const std::unique_ptr<Log,std::default_delete<Log>> &)': attempting to reference a deleted function

I think this is due to my explicitly deleting the Log copy constructor and assignment operator (but the error is almost incomprehensible). Before I proceed reintroducing the original code, anyone care to confirm that hypothesis?

WxApp.hpp

#pragma once
#pragma warning(disable:5050)

import Log;
import std.core;

using std::string;
using std::shared_ptr;
using std::unique_ptr;

class WxApp
{
public:
	WxApp();
	~WxApp();
	bool init();
	void run();
	std::unique_ptr<Log> GetLog();
private:
	unique_ptr<Log> mLog{ nullptr };

};

WxApp.cpp

#pragma once

#pragma warning(disable:5050)
#include "WxApp.hpp"

using std::cout;
using std::cin;
using std::exception;
using std::format;
using std::string;
using std::ofstream;		
using std::source_location;
using std::string;
using std::make_unique;
using std::unique_ptr;

WxApp::WxApp() = default;
WxApp::~WxApp()
{
	mLog->LogDebug("WxApp - Destructor");
	mLog->LogInfo("WxApp shutdown.");
}

bool WxApp::init()
{
	mLog = make_unique<Log>(new Log());
	mLog->SetLogLevel(LogCode::INFO);
	mLog->LogDebug("WxApp - init()");

void WxApp::run()
{
	mLog->LogDebug("WxApp - run()");
	return;
}

unique_ptr<Log> WxApp::GetLog()
{
	return mLog;
}

[Peter87]

You cannot copy a unique_ptr. Consider dereferencing the pointer and returning Log& instead.

[SimpleCoder]

Makes sense.

If I make it a shared_ptr<Log>, both in the class declaration and in the returning function, should that also solve the problem?

This I tried to do but that results in a C2665 error

Log::Log no overloaded function could convert all the argument types

The root cause of all this seems to be that, in my attempt to prevent any copies of the Log, I've deleted the copy and move constructors and assignment operators. MSVS is suggesting those lines in the Log class declaration might need to change.

Nevermind...I failed to account for all of the unique_ptr uses. As a consequence, the project builds and runs successfully, albeit with no functionality other than a couple of log file entries.

At least I have a build. Now, to add small pieces at a time.

Interestingly, no requirement to import std.core; in WxApp.cpp.

[George PlusPlus]

import std.core; and the other experimental import library variants were a wasted attempt by MS to do what C++23 did later with import std; and import std.compat;.

https://open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2465r1.pdf

I really recommend never ever use import std.core;. Use what C++23 offers for module consumption instead. import std; and import std.compat;. Nor any of the other bastardization import ideas from MS. They are non-standard, C++23 provides all you need without the overhead of using the experimental libraries project setting. Ignore what MS says here:

https://learn.microsoft.com/en-us/cpp/cpp/modules-cpp?view=msvc-170#consume-c-standard-library-as-modules-experimental

The information here is the "straight dope" now with C++23.

https://learn.microsoft.com/en-us/cpp/cpp/tutorial-import-stl-named-module?view=msvc-170

Even if you use C++23 features you can still import or #include the individual libraries you want to use. If'n you use the C++ versions of the C library it is recommended to #include, not import the libraries. For example #include <cstdio> .

Currently to use C++23 the language standard has to be set to c++:latest. MS recently added c++20 as one of the language standards available. Hopefully they will add c++23 to MSVC.

[SimpleCoder]

@George PlusPlus, thanks for that timely advice. I guess I haven't been paying attention to MSVC module implementation developments. I do recall following those instructions some time ago but don't remember why I resorted to std.core. That said, I couldn't find any std.ifc anywhere on my system so I think I deleted that attempt.

Followed the instructions and replaced all std.core with std. Project builds and runs successfully.

Although I haven't had to change any of my project options (e.g. already compiling with c++latest), I would hope that MS would someday add to that article how to perform the example build process in the VS IDE.

[SimpleCoder]

Thanks for all the ideas but I'm back with the original problem.

The moment I #include <Windows.h> in WxApp.hpp, I create 50 errors, the majority consisting of C2995 "...function template has already been defined", in 5 files - none of them mine - but including stdlib.h and string.h.

There is only one #include <Windows.h> in the entire project and nothing related to string.h or stdlib.h.

Windows.h is needed for declarations of types such as DWORD, LPSTR, LPVOID, HIWORD, etc., and winver.h is needed for access to functions such as GetFileVersionInfo() and VerQueryValue().

@seeplus

What import/include are in the .hpp files?

Could you be more specific? All of my .hpp files?

[SimpleCoder]

It appears that changing the order of the includes and imports has solved the problem, at least as far as I've currently tested.

By moving #include <Windows.h> above all the import statements, i.e.:

#include <Windows.h>
import std;
import Log;
import WxRandom;
import VersionData;
#include "WxMonth.hpp"
#include "WxTableData.hpp"
#include "WxWatch.hpp" 

and uncommenting the offending functions to test the solution, the errors have disappeared. winver.h doesn't seem to be affected by this sequence problem and it is now successfully included in the WxApp class.

Holy smokes, that could have been a little bit easier and it's ridiculous that includes with #pragam once and header guards should behave in this way.

My gratitude to all of you who offered their help.

[seeplus]

Unless you need it all, you can reduce the size of the windows header file by using #define WIN32_LEAN_AND_MEAN before #include <windows.h>

https://learn.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers

You also might want to have #define NOMINMAX which stops windows.h from defining min() and max() macros which are now part of std::algorithm

http://www.suodenjoki.dk/us/archive/2010/min-max.htm

[seeplus]

I suggest the issue is with import std.core; which is part of MS experimental library which has now been superseded by import std; in the C++ standard. MS import.core; shouldn't be used (and anything referenced as experimental really is only for testing - MS did the same with filesystem). If import std; is used then it can be safely used with #include <windows.h> either before or after. These below both compile OK (VS2022 as latest standard)

import std;

#include <windows.h>

int main() {
	std::cout << "hello\n";
}

#include <windows.h>

import std;

int main() {
	std::cout << "hello\n";
}