I have a simple question. When I open VC++, create an "Empty Project," insert the Lua 5.2.0 source code, then compile, I get no errors. However, when I do this except select "Windows Forms Application" at the beginning, I get a whole bunch of errors. What may be causing this?
EDIT:
The errors are about safe versions of certain functions:
1>..\lua-5.2.0\src\lua.c(102): error C3861: 'signal': identifier not found
1>..\lua-5.2.0\src\lua.c(178): error C3861: 'signal': identifier not found
1>..\lua-5.2.0\src\lua.c(180): error C3861: 'signal': identifier not found
1> luac.c
1>..\lua-5.2.0\src\luac.c(43): warning C4996: 'strerror': This function or variable may be unsafe. Consider using strerror_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
1> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\string.h(157) : see declaration of 'strerror'
1>..\lua-5.2.0\src\luac.c(178): warning C4996: 'fopen': This function or variable may be unsafe. Consider using fopen_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
1> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\stdio.h(234) : see declaration of 'fopen'
1> lundump.c
1> lvm.c
1>..\lua-5.2.0\src\lvm.c(53): warning C4996: 'sprintf': This function or variable may be unsafe. Consider using sprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
1> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\stdio.h(371) : see declaration of 'sprintf'
1> lzio.c
1> Generating Code...
It may be because when you create a windows form application, it is actually using managed c++ (uses .net), which I don't think lua is compatible with. Take a look at http://luaplus.org/ that might be what you're looking for. It seems like it's lua for ANY .net language (which managed c++ is)
Related
I feel sorta silly asking this question, but I just cannot find a solution anywhere on the internet.
Notes:
I am using VS2019
C++17 is enabled
My problem is the following:
I want to iterate files in a directory with std::filesystem. To do so, I need to use the directory_iterator. However, when I include the filesystem library, it doesn't find the directory_iterator, so I checked the filesystem header file. It threw me a bunch of errors. I also cannot use experimental/filesystem because for some reason the path class also has errors which make the string functions unusable.
However, when I create a fresh console application, it works fine for me. No errors, directory_iterator has been found, I can iterate without issues.
Here is a small snippet of what the errors I'm being given when trying to compile:
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.21.27702\include\experimental\filesystem(917,28): warning C4003: not enough arguments for function-like macro invocation 'concat'
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.21.27702\include\experimental\filesystem(921,1): error C2365: '_InIt': redefinition; previous definition was 'template parameter'
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.21.27702\include\experimental\filesystem(921): message : see declaration of '_InIt'
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.21.27702\include\experimental\filesystem(921,1): error C2061: syntax error: identifier '_First_InIt'
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 just discovered the hidden gem crtdbg.h which makes memory leak detection so much easier. Unfortunately, when I linked DirectX into my program today, I got some errors I've never seen before.
1>e:\program files (x86)\microsoft directx sdk (june 2010)\include\d3dx10math.h(425): error C2059: syntax error : 'constant'
1>e:\program files (x86)\microsoft directx sdk (june 2010)\include\d3dx10math.h(425): error C2091: function returns function
1>e:\program files (x86)\microsoft directx sdk (june 2010)\include\d3dx10math.h(425): error C2802: static member 'operator new' has no formal parameters
1>e:\program files (x86)\microsoft directx sdk (june 2010)\include\d3dx10math.h(426): error C2059: syntax error : 'constant'
1>e:\program files (x86)\microsoft directx sdk (june 2010)\include\d3dx10math.h(426): error C2090: function returns array
1>e:\program files (x86)\microsoft directx sdk (june 2010)\include\d3dx10math.inl(1003): error C2761: 'void *(__cdecl *_D3DXMATRIXA16::operator new(void))(size_t)' : member function redeclaration not allowed
1>e:\program files (x86)\microsoft directx sdk (june 2010)\include\d3dx10math.inl(1003): fatal error C1903: unable to recover from previous error(s); stopping compilation
It seems like when crtdbg overrides the new operator, it breaks something in the DirectX SDK (in case you didn't notice in the errors, I am using the DirectX 11 SDK). Is anything like this documented? A few searches didn't yield any results. I really hope I can continue to use these memory debugging tools, and any workarounds would be greatly appreciated!
Ok, I figured it out. I found this post via Google. (I wish Stack Overflow had shown it to me on the sidebar when I was typing this! Or maybe it did and I missed it...).
Basically, I need to move the including of crtdbg.h, stdlib.h and the definition of _CRTDBG_MAP_ALLOC to a separate header, and use the Forced Include File option under C/C++ >> Advanced in the project properties page to force that include file everywhere. This seems to make it override all other new overrides.
I'm using Boost.Python to expose JRA's BWRepLib so I can try to do some data mining on sc:bw replays in python and I've run into a small problem with the values being returned from the C++ methods. When running any old simple program such as the tutorial I get the expected value returned to python (a "hello, world" string that prints out fine). However when I run the bwreplib program I run into the problem where all the strings get truncated and certain integer returning methods return unexpected values. For example in one replay the player names in C++ return properly as player 1 being SlayerS_'BoxeR', player 2 as iloveoov. However the values printed out in python are erS_'Boxer' and eoov, missing the initial 4 bytes/chars. Another example is the player race which should be an integer value 1,2,3 or 6, however I'm getting larger unrelated values such as 97, 120, 111, and 78 however certain values such as 120 and 97 should be the same race and return the same value from in the pure C++ program. As I see no binary correlation between the numbers I suspect that perhaps this is being offset by a word in python as well and returning a value from a different location? Has anyone encountered a similar problem?
I'm pretty new at using Boost.Python and not a C++ expert. I can post the wrapper however it doesn't do much other than expose the functions such as
class_<BWrepPlayer>("BWrepPlayer")
.def("getName", &BWrepPlayer::getName)
.def("getNumber", &BWrepPlayer::getNumber)
I suspect I am supposed to do something special to wrap the functions that I am not doing. However searching online and reading through the documentation I can not find what that would be, however I'm sure it will be glaringly obvious once I find out.
Edit: Log Output
...patience...
...patience...
...found 1547 targets...
...updating 4 targets...
compile-c-c++ bin\msvc-9.0\debug\threading-multi\BWrepAPI.obj
BWrepAPI.cpp
BWrepAPI.cpp(19) : warning C4996: 'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
c:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\string.h(74) : see declaration of 'strcpy'
BWrepAPI.cpp(88) : warning C4996: 'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
c:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\string.h(74) : see declaration of 'strcpy'
BWrepAPI.cpp(245) : warning C4996: 'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
c:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\string.h(74) : see declaration of 'strcpy'
BWrepAPI.cpp(246) : warning C4996: 'strcat': This function or variable may be unsafe. Consider using strcat_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
c:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\string.h(79) : see declaration of 'strcat'
BWrepAPI.cpp(259) : warning C4996: 'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
c:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\string.h(74) : see declaration of 'strcpy'
BWrepAPI.cpp(265) : warning C4996: 'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
c:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\string.h(74) : see declaration of 'strcpy'
BWrepAPI.cpp(277) : warning C4996: 'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
c:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\string.h(74) : see declaration of 'strcpy'
BWrepAPI.cpp(323) : warning C4996: 'fopen': This function or variable may be unsafe. Consider using fopen_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
c:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\stdio.h(237) : see declaration of 'fopen'
msvc.link.dll bin\msvc-9.0\debug\threading-multi\pybwrep.pyd
Creating library bin\msvc-9.0\debug\threading-multi\pybwrep.lib and object bin\msvc-9.0\debug\threading-multi\pybwrep.exp
msvc.manifest.dll bin\msvc-9.0\debug\threading-multi\pybwrep.pyd
...updated 4 targets...