I had a piece of code that was including some Boost headers. Upon compilation I received errors like
/usr/local/include/boost/smart_ptr/shared_ptr.hpp:1041:9: error: use of undeclared identifier 'assert'
BOOST_ASSERT( deleter_.use_count() <= 1 );
^
/usr/local/include/boost/assert.hpp:60:29: note: expanded from macro 'BOOST_ASSERT'
# define BOOST_ASSERT(expr) assert(expr)
^
These errors however only occurred on Windows and macOS.
Explicitly including either <cassert> or <assert.h> before the Boost headers had no effect.
You need to #include <cassert> to bring in the assert implementation.
It's your job to define or not define NDEBUG accordingly.
I'm surprised Boost doesn't do that for you - are you using the Boost files correctly (i.e. including the files that you're supposed to)?
As it turned out I had a file called Assert.h in my include-path (a custom file of mine). On case-insensitive file systems as used by Windows and macOS, this would shadow the original assert.h header that actually defines the assert macro.
The solution therefore was simply to rename my assert-header file.
(I found the solution thanks to [Compilation Error] error: use of undeclared identifier 'assert' #15.)
Related
While looking for best pratices regarding include order, I was stumbling over this thread:
C/C++ include file order/best practices [closed]
#squelart was stating, that it is better pratice to include from local to global, as this reduces the chance of hidden dependencies. I just tested this in a VS2015 project with the following code:
StrTest.h
#pragma once
class CStrTest
{
public:
CStrTest();
~CStrTest();
std::string test;
};
StrTest.cpp
#include <string>
#include "StrTest.h"
CStrTest::CStrTest()
{
}
CStrTest::~CStrTest()
{
}
I couldn't reproduce the stated behaviour (hidden dependencie duo including string first in StrTest.cpp). The compiler gives me mulitple errors. So is this something out of the past or did I overlook something?
EDIT: VS2015 Compiler errors:
Error C4430 missing type specifier - int assumed. Note: C++ does not support default-int
Error C2039 'string': is not a member of 'std'
Error C3646 'test': unknown override specifier
So is this something out of the past
No, the hidden dependencies are the standard behaviour and do happen in modern compilers. I don't know of VS, but GCC and Clang do compile your shown program without any errors. Demo: https://wandbox.org/permlink/ATJndwrOwirpDgDd
The compiler gives me mulitple errors.
Although an "implicit" include is poor style, it is still technically well formed as far as the standard is concerned as long as the implicitly included file is guaranteed to be included by you or whoever wrote the header that includes it - standard headers have no such guarantees.
Therefore I would be against such compiler feature that considers implicit includes as errors. An explicitly enable-able warning would be much more suitable.
I think the point of hidden dependence problem discussed there is that typically each file includes several other files and if header is not self-contained then including it may work in cases when it's implicit dependences are included by some other header and break everything when those other headers change and / or get moved / removed. In short: use of headers with hidden dependencies lead to extremely fragile code.
// foo.hpp
#pragma once
#include <string> // if we remove this unrelated `StrTest.h` header will be broken
...
.
// main.cpp
#include "foo.hpp" // if we move this one line lower `StrTest.h` header will be broken
#include "StrTest.h" // accidentally works fine
...
I'm running into some issues compiling one of our programs using boost 1_62_0 under VS2012. I've previously had this compiling under VS2015 I believe (however can't verify this).
I turned on /showIncludes to get an idea of where exactly its having the problem, and I've narrowed it down to inclusion of typeindex from the VS2012 includes:
Note: including file: C:\PROGRA~2\MICROS~3.0\VC\include\crtdefs.h^M
Note: including file: \\COMPILESERVER\BASENT\dev\lib\src\third_party\boost\boost_latest_win64_vs2012\boost/limits.hpp^M
Note: including file: \\COMPILESERVER\BASENT\dev\lib\src\third_party\boost\boost_latest_win64_vs2012\boost/limits.hpp^M
Note: including file: \\COMPILESERVER\BASENT\dev\lib\src\third_party\boost\boost_latest_win64_vs2012\boost/type_traits/is_enum.hpp^M
Note: including file: \\COMPILESERVER\BASENT\dev\lib\src\third_party\boost\boost_latest_win64_vs2012\boost/type_traits/is_integral.hpp^M
Note: including file: \\COMPILESERVER\BASENT\dev\lib\src\third_party\boost\boost_latest_win64_vs2012\boost/utility/enable_if.hpp^M
Note: including file: \\COMPILESERVER\BASENT\dev\lib\src\third_party\boost\boost_latest_win64_vs2012\boost/cstdint.hpp^M
Note: including file: C:\PROGRA~2\MICROS~3.0\VC\include\typeindex^M
\\COMPILESERVER\BASENT\dev\lib\src\third_party\boost\boost_latest_win64_vs2012\boost/functional/hash/hash.hpp(236) : error C2039: 'UINT64' : is not a member of 'boost'^M
\\COMPILESERVER\BASENT\dev\lib\src\third_party\boost\boost_latest_win64_vs2012\boost/functional/hash/hash.hpp(237) : error C2039: 'UINT64' : is not a member of 'boost'^M
Note: including file: \\COMPILESERVER\BASENT\dev\lib\src\third_party\boost\boost_latest_win64_vs2012\boost/functional/hash/extensions.hpp^M
Using #pragma message, I can verify that it has using ::uint64_t within the boost namespace in cstdint.hpp
Any ideas on how to fix this?
Indeed this smells like a MACRO.
You should find out which header defines something like
#define uint64_t UINT64
You can save the preprocessor output of the failing translation unit to find this.
I'm writing a new project and want to replace GLEW with glbinding.
My setup is like this:
VS 2015, Qt 5.6, glbinding 2.0
I tried to compile quite simple code - only window (QWindow) with OpenGL context (QOpenGLContext) but got an error: glbinding is not compatible with gl.h
When I was tracking this bug I found out that file (which is imported by the glbinding/gl/gl.h) nogl.h is causing this message with the code below:
#ifdef __gl_h_
#error "glbinding is not compatible with gl.h"
#else
#define __gl_h_
#endif
Then I noticed that this is caused by the QtGui/qopenglcontext.h header (which I need for creating OpenGL context...). So when I don't include qopenglcontext.h my program compiles without error. I also noticed that this error message appears only when I include glbinding/gl/gl.h after QtGui/qopenglcontext.h. If I reverse the include order I get a bunch of errors like this:
1>C:\Qt\Qt5.6.0\5.6\msvc2015_64\include\QtGui/qopenglext.h(117): error C2065: 'GLenum': undeclared identifier
1>C:\Qt\Qt5.6.0\5.6\msvc2015_64\include\QtGui/qopenglext.h(117): error C2146: syntax error: missing ')' before identifier 'mode'
1>C:\Qt\Qt5.6.0\5.6\msvc2015_64\include\QtGui/qopenglext.h(118): error C2065: 'GLenum': undeclared identifier
1>C:\Qt\Qt5.6.0\5.6\msvc2015_64\include\QtGui/qopenglext.h(118): error C2146: syntax error: missing ')' before identifier 'target'
After all I still don't know how to solve this and what exactly is causing this error...
glbinding – like practically every other OpenGL loader – has to fiddle with the OpenGL symbol tokens to avoid namespace clashing. To this end it must interact with the OpenGL definitions in a specific way, which means you must not have included any OpenGL header, or something that includes such in turn at the moment you include the glbinding header. The preprocessor fiddling glbinding performs will prevent gl.h getting included in a way that causes trouble.
So what you must do is: Include the glbinding headers in your C++ compilation unit files before everything else (Qt headers, OpenGL helper libraries and so on).
I am trying to integrate wwise into a test project. I have a project on windows 7 using ms visual studio 2010 and this is the error I get after I try and add a necassary cpp to the project. i dont get this build error on my machine at home with the same set up, what does it mean?
------ Build started: Project: wwise test, Configuration: Debug Win32 ------
AkFilePackageLUT.cpp
c:\program files (x86)\audiokinetic\wwise v2012.2.1 build 4427\sdk\samples\soundengine\common\akfilepackagelut.h(204): error C2065: 'NULL' : undeclared identifier
c:\program files (x86)\audiokinetic\wwise v2012.2.1 build 4427\sdk\samples\soundengine\common\akfilepackagelut.cpp(117) : see reference to function template instantiation 'const CAkFilePackageLUT::AkFileEntry<T_FILEID> *CAkFilePackageLUT::LookupFile<AkFileID>(T_FILEID,const CAkFilePackageLUT::FileLUT<T_FILEID> *,bool)' being compiled
with
[
T_FILEID=AkFileID
]
c:\program files (x86)\audiokinetic\wwise v2012.2.1 build 4427\sdk\samples\soundengine\common\akfilepackagelut.h(204): error C2065: 'NULL' : undeclared identifier
c:\program files (x86)\audiokinetic\wwise v2012.2.1 build 4427\sdk\samples\soundengine\common\akfilepackagelut.cpp(140) : see reference to function template instantiation 'const CAkFilePackageLUT::AkFileEntry<T_FILEID> *CAkFilePackageLUT::LookupFile<AkUInt64>(T_FILEID,const CAkFilePackageLUT::FileLUT<T_FILEID> *,bool)' being compiled
with
[
T_FILEID=AkUInt64
]
To me it looks on the first glance like you did not specify a template parameter .
Other possible causes:
You are compiling with a debug version of the C runtime, declaring a
Standard C++ Library iterator variable in a for loop, and then
trying to use that iterator variable outside the scope of the for
loop. Compiling Standard C++ Library code with a debug version of
the C runtime implies /Zc:forScope. See Debug Iterator Support for
more information.
You may be calling a function in an SDK header file that is
currently not supported in your build environment.
Omitting necessary include files, especially if you define
VC_EXTRALEAN, WIN32_LEAN_AND_MEAN, or WIN32_EXTRA_LEAN. These
symbols exclude some header files from windows.h and afxv_w32.h to
speed compiles. (Look in windows.h and afxv_w32.h for an up-to-date
description of what's excluded.)
Identifier name is misspelled.
Identifier uses the wrong uppercase and lowercase letters.
Missing closing quote after a string constant.
Improper namespace scope. To resolve ANSI C++ Standard Library
functions and operators, for example, you must specify the std
namespace with the using directive. The following example fails to
compile because the using directive is commented out and cout is
defined in the std namespace
This error message is saying the following:
in <path...>\akfilepackagelut.h there is a definition of a function template. In fact, it is a templated method of a class. Inside that definition, on line 204, the name NULL is used. NULL is defined in header <cstddef> of the C standard library, and normally you can include that definition by including one of a lot of C/C++ headers, because most of them somehow include <cstddef>. However, akfilepackagelut.h seems to include only headers that in the VS2012 installation you are using do not include that definition, so the compiler does not know what NULL means.
The whole rest of the error message is just template error gibberish, telling you that that function template we are talking about has been instantiated twice somewhere in AkFilePackageLUT.cpp, telling you the exact locations and the template parameters and so on.
What can you do?
Well, if you can not modify the source as you say (Why? You have the source) you can't do anything but perhaps file a bug for the project. If you can modify it would be best to #include <cstddef> in akfilepackagelut.h.
I want to use a CMFCButton. When I compile, I get this error:
afxbutton.h(183): warning C4003: not enough actual parameters for macro 'SelectFont'
afxbutton.h(183): error C2226: syntax error: unexpected type 'HFONT'
It seems to be in conflict with a windows macro:
Windows SelectFont() Macro
How can I fix this ?
SelectFont is defined in Windowsx.h. To resolve the conflict, find any #include for Windowsx.h in your project and move it after the #include for the MFC controls. Maybe to the end of your stdafx.h.
The same problem can be seen here (note BCGSoft is the company that created the MFC controls, so the same situation applies)