While playing around with the C++11 features of Visual Studio 2012, I encountered strange errors when including the "ppltasks.h" header file (which is included via the "future" header file:
Main.cpp
1>c:\program files (x86)\microsoft visual studio 11.0\vc\include\ppltasks.h(3306): error C2512: 'Concurrency::details::_PPLTaskHandle<Concurrency::details::_NormalizeVoidToUnitType<void>::_Type,Concurrency::task<std::pair<Concurrency::details::_Unit_type,Concurrency::details::_CancellationTokenState *>>::_ContinuationTaskHandle<_InternalReturnType,_TaskType,_Function,Concurrency::details::_FunctionTypeTraits<_Function,_ReturnType>::_Takes_task,Concurrency::details::_TaskTypeTraits<void,false>::_AsyncKind>,Concurrency::details::_ContinuationTaskHandleBase>' : no appropriate default constructor available
1> with
1> [
1> _InternalReturnType=std::pair<Concurrency::details::_Unit_type,Concurrency::details::_CancellationTokenState *>
1> , _Function=Concurrency::||::<lambda_06496b162c644bf2f90c850c3dfa7d5c>
1> , _ReturnType=std::pair<Concurrency::details::_Unit_type,Concurrency::details::_CancellationTokenState *>
1> ]
The error is longer, but you get the gist of it. Has anybody else encountered such an error message from simply including the "future" header, and is there a known solution? Thanks.
Turns out that the Project Settings must have language extensions enabled for the header to compile correctly (as of now).
Related
My project needs to use both Micorsoft Visual C++ math.h and Intel MKL math.h.
Building with verbose details, I get:
1> Note: including file: C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\cmath
1> Note: including file: E:\3rdParty\MKL\2017.1.143\windows\compiler\include\math.h
1> Note: including file: C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\../../vc/include/math.h
1> Note: including file: C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\crtdefs.h
1> E:\3rdParty\MKL\2017.1.143\windows\compiler\include\math.h(1577): warning C4005: 'HUGE_VALF' : macro redefinition
1> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\../../vc/include/math.h(104) : see previous definition of 'HUGE_VALF'
1> E:\3rdParty\MKL\2017.1.143\windows\compiler\include\math.h(1579): warning C4005: 'HUGE_VALL' : macro redefinition
1> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\../../vc/include/math.h(105) : see previous definition of 'HUGE_VALL'
1> E:\3rdParty\MKL\2017.1.143\windows\compiler\include\math.h(1581): warning C4005: 'HUGE_VAL' : macro redefinition
1> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\../../vc/include/math.h(96) : see previous definition of 'HUGE_VAL'
The "'HUGE_VALF' : macro redefinition" message is the one that made me be suspicious.
At first I just disabled that warning, but considering that this option would only mask a potential problem, I am looking for an alternative solution.
From lines 1 and 2, you can see that Visual Studio's cmath does not include Visual Studio's math.h, as it should, but MKL's file with the same name.
How can I set my CMakeLists.txt file so that the compiler can pick the right include files?
Just wrap one library.
For example, create header file:
#pragma once
namespace imath {
double sin(double a);
}
And in cpp
#include "Wrapper.h"
#include <intel/math.h>
namespace imath {
double sin(double a) {
return ::sin(a);
}
}
Do this for every symbol you need to use in common source.
And do not include C version of math.h you are using C++ so #include <cmath>.
I'm getting the following error when compiling in release mode.
1>d:\users\eyal\projects\code\yalla\core\src\runbox\win32\window.cpp : fatal error C1001: An internal error has occurred in the compiler.
1> (compiler file 'f:\dd\vctools\compiler\utc\src\p2\main.c', line 249)
1> To work around this problem, try simplifying or changing the program near the locations listed above.
1> Please choose the Technical Support command on the Visual C++
1> Help menu, or open the Technical Support help file for more information
1> link!RaiseException()+0x48
1> link!CxxThrowException()+0x65
1> link!std::_Xout_of_range()+0x1f
1> link!InvokeCompilerPass()+0x1b4e2
1> link!InvokeCompilerPass()+0x22efe
1> link!InvokeCompilerPass()+0x2332e
1> link!InvokeCompilerPass()+0x232f9
1> link!InvokeCompilerPass()+0x233cb
1> link!InvokeCompilerPass()+0x22b04
1> link!InvokeCompilerPass()+0x22d86
1> link!DllGetC2Telemetry()+0x115837
1>
1> 1>
1>LINK : fatal error LNK1257: code generation failed
I'm using VS2015 Update 2 RC.
I'm not sure but maybe it's a bug in the optimizer?
The code that causes it is as follow:
window.h
class Window {
public:
Window();
~Window();
void show();
void hide();
private:
class NativeControl;
std::unique_ptr<NativeControl> _window;
};
window.cpp
class Window::NativeControl : public NativeWindow {
public:
NativeControl() : NativeWindow() { }
};
Window::Window()
: _window(std::make_unique<Window::NativeControl>()) {
}
Window::~Window() {
}
void Window::show()
{
_window->show(WindowShowMode::Show);
}
void Window::hide()
{
_window->show(WindowShowMode::Hide);
}
NativeWindow is the native Window of whatever OS.
Here is a working code compiled with GCC 5.1: https://ideone.com/4YvjRK
Just to make a note.
If I'll remove the inheritance and replace it with something like this.
class Window::NativeControl {
public:
void show(WindowShowMode showMode)
{
}
};
It will work fine!
Here is the same code compiled with GCC 5.1 with no inheritance: https://ideone.com/Mu0A42
What seems to cause this behaviour is the derivation of NativeControl from NativeWindow.
The steps to reproduce it as as follow:
Remove the dtor declaration and definitions from the Window class.
Try to Build (not Rebuild).
The compiler will complain and give you bunch of errors.
1>C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\include\memory(1194): error C2338: can't delete an incomplete type 1> 1> 1>C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\include\memory(1195): warning C4150: deletion of pointer to incomplete type 'Yalla::Window::NativeControl'; no destructor called
1>
d:\Users\Eyal\Projects\Code\Yalla\core\src\runbox\include\window.h(13):
note: see declaration of 'Yalla::Window::NativeControl' 1>
window.cpp 1> 1>Build FAILED.
Add back the dtor to the Window class.
Build again (not Rebuild).
At this point the compiler should complain with the following error "fatal error C1001: An internal error has occurred in the compiler."
The interesting part is that doing rebuild seems to fix the problem!
What I want to achieve is basically have the actual implementation of NativeWindow in a different file, mostly for simplicity and not so much about reusability.
I guess that instead of doing that in inheritance that maybe confuses the unique_ptr template I can also do that through composition and expose the instance of NativeWindow through a getter and it might work but the question is whether there are better ways to do it?
I'm relearning C++ after a very long time I didn't touch it so if some of the things I'm doing don't make sense, please tell me about it!
Update:
The C++ standard says:
The template parameter T of unique_ptr may be an incomplete type.
I found a post about it in Herb Sutter's blog.
similar error with
(compiler file 'f:\dd\vctools\compiler\utc\src\p2\main.c', line 255)
was fixed changing Properties->Linker->Optimization->Link Time Code Generation
from /LTCG:incremental to /LTCG
Studio 2015 Update 3
I had a similar fatal error while building a trivial C++ command line app and using Microsoft Visual Studio Community 2019, version 16.6.2.
Changing the default /LTCG:incremental to /LTCG in project -> properties -> linker -> optimization for release configuration fixed the problem.
Just to add, this error started after one of the recent VS2019 updates (not sure which specific one).
I resolved this issue to link big library in 64-bit. The Visual Studio tries with Default (32-bit linking).
Configuration Properties -> Advanced -> Preferred Build Tool Architecture -> 64-bit (x64)
The error C1001 related to compiler file p0io.c is mainly caused by enabling "Use Unicode UTF-8" for worldwide language supporting Region Settings. You could see the link about the concrete reason. You could click
Time &Language -> Region-> Additional date, time, ®ional settings-> Region-> Administrative->Change system locale
and turn off UTF-8.
I have a strange situation here. I am trying to use the Botan crypto library with VS2015 (because some other parts of the project use some heavy C++11 code which VS2013 is unable to compile) and I get a pretty long compilation error (see below).
After trying out various things, I came to the conclusion, that even if one of the botan headers is included in the compiled c++ source file, the compiler will throw the error below. Right now I have a single line in the file:
#include <botan/botan.h>
and this is the error I get:
C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\xmemory0(876): error C2664: 'Botan::secure_allocator<_Newfirst>::secure_allocator(const Botan::secure_allocator<_Newfirst> &)': cannot convert
argument 1 from 'std::_Wrap_alloc<Botan::secure_allocator<Botan::byte>>' to 'const Botan::secure_allocator<_Newfirst> &'
with
[
_Newfirst=std::_Container_proxy
]
C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\xmemory0(876): note: Reason: cannot convert from 'std::_Wrap_alloc<Botan::secure_allocator<Botan::byte>>' to 'const Botan::secure_allocator<_Ne
wfirst>'
with
[
_Newfirst=std::_Container_proxy
]
C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\xmemory0(876): note: No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\vector(587): note: see reference to function template instantiation 'std::_Wrap_alloc<Botan::secure_allocator<_Newfirst>>::_Wrap_alloc<std::_Wr
ap_alloc<Botan::secure_allocator<Botan::byte>>>(_Other &) noexcept' being compiled
with
[
_Newfirst=std::_Container_proxy,
_Other=std::_Wrap_alloc<Botan::secure_allocator<Botan::byte>>
]
C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\vector(587): note: see reference to function template instantiation 'std::_Wrap_alloc<Botan::secure_allocator<_Newfirst>>::_Wrap_alloc<std::_Wr
ap_alloc<Botan::secure_allocator<Botan::byte>>>(_Other &) noexcept' being compiled
with
[
_Newfirst=std::_Container_proxy,
_Other=std::_Wrap_alloc<Botan::secure_allocator<Botan::byte>>
]
C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\vector(585): note: while compiling class template member function 'void std::_Vector_alloc<std::_Vec_base_types<_Ty,_Alloc>>::_Free_proxy(void)
'
with
[
_Ty=Botan::byte,
_Alloc=Botan::secure_allocator<Botan::byte>
]
C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\vector(552): note: see reference to function template instantiation 'void std::_Vector_alloc<std::_Vec_base_types<_Ty,_Alloc>>::_Free_proxy(voi
d)' being compiled
with
[
_Ty=Botan::byte,
_Alloc=Botan::secure_allocator<Botan::byte>
]
C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\vector(679): note: see reference to class template instantiation 'std::_Vector_alloc<std::_Vec_base_types<_Ty,_Alloc>>' being compiled
with
[
_Ty=Botan::byte,
_Alloc=Botan::secure_allocator<Botan::byte>
]
c:\Botan\include\botan-1.11\botan/rng.h(43): note: see reference to class template instantiation 'std::vector<Botan::byte,Botan::secure_allocator<Botan::byte>>' being compiled
NMAKE : fatal error U1077: 'C:\PROGRA~1\MICROS~3.0\VC\bin\cl.exe' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 14.0\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 14.0\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
Since I was able to compile and run the botan tests, I have the feeling that I missed something, but I have no idea what. Does anyone has any experience with this?
(BTW: The same code compiles nicely with g++ 4.9)
Looking at the sources, it seems that Botan::secure_allocator doesn't provide a template constructor of the form
template<class U> secure_allocator(const secure_allocator<U>& other);
This is required by the Standard. In the current working draft, N4527, the relevant bits are in [17.6.3.5] Table 28 - Allocator requirements; also useful is the example in paragraph 9.
So, we can't blame the standard library implementation that comes with VC 14 for requiring this in order to compile. The error is on Botan's side in my opinion.
A quick fix is to add such a definition to Botan::secure_allocator:
template<class U> secure_allocator(const secure_allocator<U>&) BOTAN_NOEXCEPT { }
Since instantiations of this allocator template don't have any non-static data members, an empty body should be fine. However, I'm not familiar with the library, and we're talking about cryptography here, so, before using this to do any serious stuff, please confirm the change with the library authors.
Another possible workaround:
I've noticed that the code that calls the mixed-type constructor seems to only be enabled when iterator debugging is enabled, which happens by default in Debug mode.
Have you tried compiling in release mode? If my observations are correct, you won't get this error anymore, since the additional machinery for iterator debugging will be disabled.
To get the same behaviour in Debug mode, set the _ITERATOR_DEBUG_LEVEL macro to 0 globally.
Debug iterators can be useful to detect errors (as long as the performance hit doesn't affect you), so I wouldn't use this as a permanent fix, but it could be useful as a temporary workaround if you don't want to modify the Botan header file.
This could also explain why you were able to compile the tests: maybe they're compiled in release mode, or, anyway, with a combination of settings that disables iterator debugging?
Every time I build my project my Build output window is filled (one instance for every cpp file) with
1>d:\program files\microsoft sdks\windows\v7.1\include\sal_supp.h(57): warning C4005: '__useHeader' : macro redefinition
1> d:\program files\microsoft visual studio 12.0\vc\include\sal.h(2886) : see previous definition of '__useHeader'
1>d:\program files\microsoft sdks\windows\v7.1\include\specstrings_supp.h(77): warning C4005: '__on_failure' : macro redefinition
1> d:\program files\microsoft visual studio 12.0\vc\include\sal.h(2896) : see previous definition of '__on_failure'
It's not really a problem except that it makes it hard to parse the actual build errors when I break something. How can I fix the root of this error? Or at least silence it?
From a comment under the original question:
VS2012 C++ warning C4005: '__useHeader': macro redefinition
Long story short, its a bug in VS, with no real workarounds.
I have chosen to just silence the specific warning code, which does silence all instances of macro re-definitions. But now I can actually read my build output so whatever I guess.
http://msdn.microsoft.com/en-us/library/jj715718.aspx
I am having some trouble converting an old project from VS6 to VS2005. At one place in the code it uses the type variant_t so it includes comdef.h for this purpose. comdef.h then includes comutil.h which generates these errors for me:
c:\program files\microsoft visual studio 8\vc\include\comutil.h(978) : error C2535: '_variant_t::_variant_t(int) throw()' : member function already defined or declared
c:\program files\microsoft visual studio 8\vc\include\comutil.h(970) : see declaration of '_variant_t::_variant_t'
c:\program files\microsoft visual studio 8\vc\include\comutil.h(1007) : error C2535: '_variant_t::operator int(void) const' : member function already defined or declared
c:\program files\microsoft visual studio 8\vc\include\comutil.h(998) : see declaration of '_variant_t::operator int'
c:\program files\microsoft visual studio 8\vc\include\comutil.h(1037) : error C2535: '_variant_t &_variant_t::operator =(int)' : member function already defined or declared
c:\program files\microsoft visual studio 8\vc\include\comutil.h(1029) : see declaration of '_variant_t::operator ='
c:\program files\microsoft visual studio 8\vc\include\comutil.h(1331) : error C2084: function '_variant_t::_variant_t(int) throw()' already has a body
c:\program files\microsoft visual studio 8\vc\include\comutil.h(970) : see previous definition of '{ctor}'
c:\program files\microsoft visual studio 8\vc\include\comutil.h(1588) : error C2084: function '_variant_t::operator int(void) const' already has a body
c:\program files\microsoft visual studio 8\vc\include\comutil.h(998) : see previous definition of '.H'
c:\program files\microsoft visual studio 8\vc\include\comutil.h(2006) : error C2084: function '_variant_t &_variant_t::operator =(int)' already has a body
c:\program files\microsoft visual studio 8\vc\include\comutil.h(1029) : see previous definition of '='
There is probably some configuration that is incorrect, some define missing or some include file I should have included but I can't seem to find the problem. Any pointers in the right direction is much appreciated
This looks like one of two things, an include order problem or as you stated something not getting defined but I am leaning towards the first one. You might want to check msdn and make sure there are no restrictions on when comutil.h can be included (I know this is an issue if you include winsock2.h before windows.h). There is also an option under C/C++ > Advanced to Show Includes (/showIncludes option from the command-line) which is generally helpful when trying to track issues like this down.
Does your own code do something like this:
#define long int