I'm using clang++ that links to MSVC.
I compiled shaders (DirectXTK\Shaders) and included SpriteBatch and SpriteFont in my source code.
If I include just the header files (.h), I get linking errors; if I include source files (.cpp; with or without .h), I get this:
SpriteBatch.cpp:532:27: error: expected unqualified-id
size_t newSize = std::max(InitialQueueSize, mSpriteQueueArraySize * 2);
^
C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\shared\minwindef.h:193:29: note: expanded from macro 'max'
#define max(a,b) (((a) > (b)) ? (a) : (b))
I tried to find the solution on the GitHub issues page of DirectXTK, on this website and on the web, but didn't find anything helpful.
The Windows headers define a 'min' and 'max' macro that interacts poorly with std::min/std::max from <algorithm>.
In all my templates and tests, I define NOMINMAX before using Windows.h to avoid this problem. It's generally a better practice. If you still need to use a macro form while doing this, you can use __min/_max.
#define WIN32_LEAN_AND_MEAN
#define NOMINMAX
#define NODRAWTEXT
#define NOGDI
#define NOBITMAP
#define NOMCX
#define NOSERVICE
#define NOHELP
#include <Windows.h>
See this other thread and this blog post
Related
is it possible to port Eigen, a C++ template library for linear algebra, to IAR workbench for ARM. I have tried to do this while but am getting following compile errors
Error[Pe337]: linkage specification is incompatible with previous "__nounwind __iar_builtin_get_CONTROL" (declared at line 58 of "C:\Program Files (x86)\IAR Systems\Embedded Workbench 8.3\arm\inc\c\iccarm_builtin.h") C:\Program Files (x86)\IAR Systems\Embedded Workbench 8.3\arm\CMSIS\Core\Include\cmsis_gcc.h 151
This is the entire error I get when I use the preprocessors
__GNUC__
__arm__
if I dont use these preprocessors I get an error from a #error preprocessor
from the Eigen file Macros.h
"error Please tell me what is the equivalent of attribute((aligned(n))) for your compiler"
#if (defined __CUDACC__)
#define EIGEN_ALIGN_TO_BOUNDARY(n) __align__(n)
#elif EIGEN_COMP_GNUC || EIGEN_COMP_PGI || EIGEN_COMP_IBM || EIGEN_COMP_ARM
#define EIGEN_ALIGN_TO_BOUNDARY(n) __attribute__((aligned(n)))
#elif EIGEN_COMP_MSVC
#define EIGEN_ALIGN_TO_BOUNDARY(n) __declspec(align(n))
#elif EIGEN_COMP_SUNCC
// FIXME not sure about this one:
#define EIGEN_ALIGN_TO_BOUNDARY(n) __attribute__((aligned(n)))
#else
//#define EIGEN_ALIGN_TO_BOUNDARY(n) __declspec(align(n))
#error Please tell me what is the equivalent of __attribute__((aligned(n))) for your compiler
#endif
I have it working for visual c++ but not IAR. All includes are added.
These errors change based on the preprocessors I use to try to configure Eigen. Is it possible to use Eigen with IAR?
To add to #chtz answer, here's how I got the EIGEN_ALIGN_TO_BOUNDARY macro to work with IAR, in a way that is consistent with the eigen library:
1: add this to top of Macros.h to identify the IAR ARM compiler
/// \internal EIGEN_COMP_ICCARM set to 1 if the compiler is IAR eWARM
#if defined(__ICCARM__)
#define EIGEN_COMP_ICCARM 1
#else
#define EIGEN_COMP_ICCARM 0
#endif
2: add this case to where EIGEN_ALIGN_TO_BOUNDARY(n) is defined in Macros.h
#elif EIGEN_COMP_ICCARM
#define IAR_STRINGIFY(a) #a
#define IAR_ALIGN_STR(n) IAR_STRINGIFY(data_alignment=n)
#define EIGEN_ALIGN_TO_BOUNDARY(n) _Pragma(IAR_ALIGN_STR(n))
EIGEN_ALIGN_TO_BOUNDARY(n) should now correctly expand to _Pragma("data_alignment=n")
I have now gotten it to build and run. Thank you #chtz for the EIGEN_DONT_ALIGN macro suggestion. This is how I did it. I am unsure however what repercussions this has on the library itself, as in what features this may take away. I did this:
include the directory to where you installed Eigen as the additional includes.
in lines 86, 105, 125, 145 in file DenseStorage.h change the lines
EIGEN_ALIGN_TO_BOUNDARY(8) T array[Size];
to their respective
_Pragma("data_alignment=8") T array[Size];
(pay attention to the number)
in Macros.h , line 665 , comment out the "#error Please tell me what is the"
finally, define the macro EIGEN_DONT_ALIGN in the preprocessor settings.
This is what worked for Eigen 3.3.7
I'm trying to debug the includes of my project's main file. Here's my include code.
//Gameplay
#include "gameplay.h"
//LibNoise
#include <noise/noise.h>
//Console Window
#ifndef _WINDOWS_
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#undef KEY_EVENT
#undef MOUSE_EVENT
#endif
#include <io.h>
#include <fcntl.h>
//RakNet
#include "MessageIdentifiers.h"
#include "RakPeerInterface.h"
#include "BitStream.h"
#include "RakNetTypes.h"
//My Includes
#include "Island.h"
The problem is, gameplay.h includes a file (specifically ScriptController.h) where there's an enum that contains the words KEY_EVENT and MOUSE_EVENT which is included through some includes in windows.h (specifically wincon.h). This breaks the enum and I get errors during compilation. Note, it is actually including windows.h because _WINDOWS_ isn't defined at this point according to MSVS (so it's not like it's defined before gameplay.h or something).
I can't see why this would be a problem as gameplay.h is included before windows.h which should mean that I would get no trouble with replacement of the terms in the enum? Undefining them doesn't help either.
Where did I go wrong? Is there any way I can "debug" the preprocessor and see the output from the preprocessor that is causing this syntax error and some kind of #include chain? I want to be able to fix this myself next time if it occurs.
Here's the errors
Error 3 error C2065: 'CALLBACK_COUNT' : undeclared identifier c:\users\pf\downloads\gameplay-master\gameplay\src\scriptcontroller.h 1024 1 testerino2
Error 1 error C2059: syntax error : 'constant' c:\users\pf\downloads\gameplay- master\gameplay\src\scriptcontroller.h 769 1 testerino2
Error 2 error C3805: 'constant': unexpected token, expected either '}' or a ',' c:\users\pf\downloads\gameplay-master\gameplay\src\scriptcontroller.h 769 1 testerino2
Here's the wincon.h defines
#define KEY_EVENT 0x0001 // Event contains key event record
#define MOUSE_EVENT 0x0002 // Event contains mouse event record
Here's the offending code lines of ScriptController.h
762| enum ScriptCallback
763| {
764| INITIALIZE = 0,
...
768| RESIZE_EVENT,
769| KEY_EVENT,
770| MOUSE_EVENT,
771| TOUCH_EVENT,
...
775| GAMEPAD_EVENT,
776| CALLBACK_COUNT,
777| INVALID_CALLBACK = CALLBACK_COUNT
778| };
...
1024| std::vector<std::string> _callbacks[CALLBACK_COUNT];
To avoid clashes with windows.h defines, I'd recommend making your own header file that:
Defines any macros that affect windows.h, such as WIN32_LEAN_AND_MEAN
Does #include <winsock2.h> if used, and #include <windows.h>
Does #undef on any annoying macros
Then make sure every source file that might come across a Windows include, includes this header. You could perhaps use a compiler feature to inject the header into all units.
I was trying to build OpenCV version 2.4.8 to use it with CodeBlocks and MinGw. I followed the instructions from here. But I got the following error. I have no clue how to solve it. I didn't find anything useful by searching in the net.
This is also not solving.
I don't want to mess with the openCV code, I intend to use OpenCV in my project and this is first time I am using it.
[ 26%] Built target pch_Generate_opencv_highgui
[ 26%] Building CXX object modules/highgui/CMakeFiles/opencv_highgui.dir/src/window_w32.cpp.obj
C:\Program Files (x86)\opencv\sources\modules\highgui\src\window_w32.cpp: In function 'void cvSetModeWindow_W32(const char*, double)':
C:\Program Files (x86)\opencv\sources\modules\highgui\src\window_w32.cpp:477: error: 'MonitorFromRect' was not declared in this scope
C:\Program Files (x86)\opencv\sources\modules\highgui\src\window_w32.cpp: In function 'LRESULT MainWindowProc(HWND__*, UINT, WPARAM, LPARAM)':
C:\Program Files (x86)\opencv\sources\modules\highgui\src\window_w32.cpp:1355: error: 'MonitorFromRect' was not declared in this scope
mingw32-make.exe[2]: *** [modules/highgui/CMakeFiles/opencv_highgui.dir/src/window_w32.cpp.obj] Error 1
mingw32-make.exe[1]: *** [modules/highgui/CMakeFiles/opencv_highgui.dir/all] Error 2
mingw32-make.exe: *** [all] Error 2
I tried to manually include the prototype of the function in the file, but then it comes to linking error.
will anyone please tell me what may have gone wrong here? How can I solve it?
It seems All the changes from recent commit is not reflected in your check out. To resolve the problems, make the following changes:
In modules/highgui/src/precomp.hpp, add the + marked line:
#if defined WIN32 || defined WINCE
+ #if !defined _WIN32_WINNT
+ #ifdef HAVE_MSMF
+ #define _WIN32_WINNT 0x0600 // Windows Vista
+ #else
+ #define _WIN32_WINNT 0x0500 // Windows 2000
+ #endif
+ #endif
+
#include <windows.h>
And in modules/highgui/src/window_w32.cpp, remove the - marked lines:
#if defined WIN32 || defined _WIN32
-#define COMPILE_MULTIMON_STUBS // Required for multi-monitor support
-#ifndef _MULTIMON_USE_SECURE_CRT
-# define _MULTIMON_USE_SECURE_CRT 0 // some MinGW platforms have no strncpy_s
-#endif
-
-#if defined SM_CMONITORS && !defined MONITOR_DEFAULTTONEAREST
-# define MONITOR_DEFAULTTONULL 0x00000000
-# define MONITOR_DEFAULTTOPRIMARY 0x00000001
-# define MONITOR_DEFAULTTONEAREST 0x00000002
-# define MONITORINFOF_PRIMARY 0x00000001
-#endif
-#ifndef __inout
-# define __inout
-#endif
-
#ifdef __GNUC__
# pragma GCC diagnostic ignored "-Wmissing-declarations"
#endif
#include <commctrl.h>
-#include <winuser.h>
#include <stdlib.h>
#include <string.h>
This will solve the build error.
I had the same problem when building OpenCV 3.0.0 RC1 with mingw32 and the TBB library enabled.
The fix from Rajdhar is already included in the precomp.h file. However, due when building OpenCV with the TBB library, the extra includes trigger the same problem again.
I provisionally solved the issue by moving the definition of _WIN32_WINNT indicated by Rajdhar to an earlier point in the file, before the opencv/core includes:
#ifndef __HIGHGUI_H_
#define __HIGHGUI_H_
#include "opencv2/highgui.hpp"
// MOVED UP
#if defined WIN32 || defined WINCE
#if !defined _WIN32_WINNT
#ifdef HAVE_MSMF
#define _WIN32_WINNT 0x0600 // Windows Vista
#else
#define _WIN32_WINNT 0x0500 // Windows 2000
#endif
#endif
#include <windows.h>
#undef small
#undef min
#undef max
#undef abs
#endif
// END MOVED
#include "opencv2/core/utility.hpp"
#include "opencv2/core/private.hpp"
#include "opencv2/imgcodecs.hpp"
#include "opencv2/imgproc/imgproc_c.h"
#include "opencv2/imgcodecs/imgcodecs_c.h"
#include "opencv2/highgui/highgui_c.h"
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <limits.h>
#include <ctype.h>
#include <assert.h>
// MOVED FROM HERE
#ifdef HAVE_TEGRA_OPTIMIZATION
#include "opencv2/highgui/highgui_tegra.hpp"
#endif
I've had exactly the same problem, and after a quick glance at the file winuser.h, I knew what's going on and added necessary macros to CFLAGS and CXXFLAGS in the command line:
CFLAGS=-D_WIN32_WINNT=0x0500 CXXFLAGS=-D_WIN32_WINNT=0x0500 make
However, the problem was still unsolved. Adding VERBOSE=1 showed that the custom CFLAGS and CXXFLAGS did not take effect at all. It was wierd and I think it should have something to do with my environment, though, i still could not figure it out. Anyway, #Rajdhar 's answer solved my problem, thanks.
I'm pretty rusty in C++, so forgive me for any stupid comments/questions. Right now I'm working in Microsoft Visual C++ 2010 Express. I have two files - a source and a header - and VS is recognizing the header file when I include it, but it cannot find any definitions from within the header file. It shows me 'Error: identifier "RAW_PACKET_SIZE" is undefined'. The code was provided as a sample to work with a device's API, so it should work. I'm assuming the problem is with the VS setup. Here's some intro code form each:
recorder.cpp
#include <vector>
#include "APIW32.h"
#pragma comment(lib,"APIW32.lib")
int devID;
float* buf = new float[RAW_PACKET_SIZE]; // error is here, at 'RAW_PACKET_SIZE'
APIW32.h
#pragma once
#ifdef EXPORTS
#define API __declspec(dllexport)
#else
#define API __declspec(dllimport)
#endif
#define MIN_BW 0.301003456
#define MAX_BW 10100000
#define RAW_PACKET_SIZE 299008
UPDATE:
It appears that the error was only appearing in Intellisense, and not as an actual build error. Moral of the story - Intellisense is not always right!
Try float* buf = new float[RAW_PACKET_SIZE];
i recently added:
#define NOMINMAX
#include <Windows.h>
#include <algorithm>
to my main.cpp in order to use
std::max( x , x ); // x is just a placeholder and not actual anything
std::min( x , x );
but i can't use std::max()/std::min() in other files.
error C2589: '(' : illegal token on right side of '::'
error C2059: syntax error : '::'
i tried to add #define NOMINMAX in my other files, but fails. what is the clue?
i looked around before asking, but i don't understand the answer Possible problems with NOMINMAX on Visual C++
If you're really desperate, put parentheses around the function names:
(std::min)(x, y);
This syntax won't apply a function-like macro. (Formally, to apply a function-like macro the name of the macro must be followed by optional white space then a '('.)
Define NOMINMAX via a compiler flag:
> cl.exe -DNOMINMAX ...
this will then be defined for all of the source files. I don't use the IDEs but this page provides guidance on navigating the IDE to set this: Using STL in Windows Program Can Cause Min/Max Conflicts
:
Simply define the NOMINMAX preprocessor symbol. This can be done in the Developer Studio project under Build, Settings, on the C/C++ tab, in the Preprocessor category. This will suppress the min and max definitions in Windef.h.
If you define NOMINMAX, because you prefer the STL version, then you may get problems while including gdiplus.h, which uses the min/max macro.
As solution you need to include the STL headers and use "using namespace std" before you include the gdiplus.h.
In example:
#define NOMINMAX
// Include C++ headers
#include <algorithm>
using namespace std;
// Include Windows headers
#include <windows.h>
#include <gdiplus.h>
It's likely that your problem is that you #define NOMINMAX after you #include "windows.h". It is important that the #define come first.
The reason is that windows.h (actually I think windef.h, which is included by windows.h) has code similar to this:
#ifndef NOMINMAX
#define min(x,y) ((x) < (y) ? (x) : (y))
#define max(x,y) ((x) > (y) ? (x) : (y))
#endif
So #define NOMINMAX is telling the compiler (or actually the preprocessor) to skip over the definitions of min and max, but it will only apply if you do it before you #include "windows.h".
In Visual Studio, Adding 'NOMINMAX' to C++ preprocessor properties fixed my issue.
Open project properties -> C/C++ -> Preprocessor -> Preprocessor Definitions -> Add 'NOMINMAX'.