I want my application to work in win32 and x64 platform. I have added below code in header file but I am getting C4005 warning. How can I avoid this?
#ifdef WIN32
#define SIZEOF_ANALYSIS_INFO 168
#endif
#ifdef _WIN64
#define SIZEOF_ANALYSIS_INFO 172
#endif
The _WIN32 macro is always defined when compiling on Windows these days, even in 64 bit compiles. You'll want to rearrange your code a bit:
#ifdef _WIN64
#define SIZEOF_ANALYSIS_INFO 172
#elif defined(_WIN32)
#define SIZEOF_ANALYSIS_INFO 168
#endif
If you're always compiling this with VC, you can just use #else in the middle.
Better yet would to be to use the sizeof operator with whatever struct is holding the analysis info, if possible.
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 porting a code from Windows to CentOS but I'm confronting with a problem that I've never seen before.
Given that function declaration (there are many more) :
byte getValueInt8() const throw(.../*Exception*/);
I get this error:
error: expected type-specifier before ‘...’ token unsigned short getValueInt8() const throw(.../*Exception*/);
Of course I've checked the internet and I've found that it is a visibility problem in shared objects.
This website https://gcc.gnu.org/wiki/Visibility explains that but I had already done this when I read it.
My defines are:
#if defined(_MSC_VER)
#include <winsock2.h>
#ifdef MFTINTERFACE_EXPORTS
#define EXPORT_IMPORT __declspec(dllexport)
#else
#define EXPORT_IMPORT __declspec(dllimport)
#endif
#elif defined(_GCC)
#include <arpa/inet.h>
#include "CmnSocketsDef.h"
#include "CmnDefs.h"
#define EXPORT_IMPORT __attribute__((visibility("default")))
#else
#define EXPORT_IMPORT
#define IMPORT
#pragma warning Unknown dynamic link import/EXPORT_IMPORT semantics.
#endif
Of course, all EXPORT_IMPORT are well set in my code.
The code, before modification compiles in Windows.
throw(...) as an exception specification isn't legal c++.
I can only assume you've encountered a Microsoft abomination extension.
You'll need to remove it. In any case the only exception specifier that makes any sense in reality is nothrow (or throw() if you're using an ancient compiler).
Indeed, here's the smoking gun:
https://msdn.microsoft.com/en-us/library/wfa0edys.aspx
proposal to deprecate:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3051.html
I have a Visual Studio 2015 project which uses the afxcmn header and is having a lot of "is undefined" errors.
I read in the documentation those data types are included in commctrl.h which is already included in the Visual Studio project as external dependency.
// Adds a group to the control.
AFX_ANSI_DEPRECATED int InsertGroup(_In_ int index, _In_ PLVGROUP pgrp);
// Sets information about the specified group (by ID) in the control.
AFX_ANSI_DEPRECATED int SetGroupInfo(_In_ int iGroupId, _In_ PLVGROUP pGroup);
// Retrieves information for the specified group in the control.
AFX_ANSI_DEPRECATED int GetGroupInfo(_In_ int iGroupId, _Out_ PLVGROUP pgrp) const;
That is some code example of the afxcmn.h which gives those errors.
I dont know if I have to configure something else in the project to include the commctrl header
yes, PLVGROUP is defined in commctrl.h, but it depends on WINVER
#if (NTDDI_VERSION >= NTDDI_WINXP)
that means WINVER >= 501, see:
error-Direktive: MFC does not support WINVER less than 0x0501. Please change the definition of WINVER in your project properties or precompiled header.
So I had to change my stdafx.h
//#define WINVER 0x0500
#define WINVER NTDDI_WINXP //0x05010000
They are IntelliSense errors generated by Visual Studio 2015.
My environment is Windows 10 1903/VS2017
I don't know exactly why, but this solves the problem for me:
FYI, this is the original stdafx.h in my project that produce the error in the question:
#pragma once
#ifndef VC_EXTRALEAN
#define VC_EXTRALEAN // Exclude rarely-used stuff from Windows headers
#endif
// Modify the following defines if you have to target a platform prior to the ones specified below.
// Refer to MSDN for the latest info on corresponding values for different platforms.
#ifndef WINVER // Allow use of features specific to Windows 95 and Windows NT 4 or later.
#define WINVER 0x0400 // Change this to the appropriate value to target Windows 98 and Windows 2000 or later.
#endif
#ifndef _WIN32_WINNT // Allow use of features specific to Windows NT 4 or later.
#define _WIN32_WINNT 0x0400 // Change this to the appropriate value to target Windows 98 and Windows 2000 or later.
#endif
#ifndef _WIN32_WINDOWS // Allow use of features specific to Windows 98 or later.
#define _WIN32_WINDOWS 0x0410 // Change this to the appropriate value to target Windows Me or later.
#endif
#ifndef _WIN32_IE // Allow use of features specific to IE 4.0 or later.
#define _WIN32_IE 0x0400 // Change this to the appropriate value to target IE 5.0 or later.
#endif
#define _ATL_CSTRING_EXPLICIT_CONSTRUCTORS // some CString constructors will be explicit
......
after adding these two lines bellow "#pragma once" the problem is solved:
#define WINVER 0x0603
#define _WIN32_WINNT 0x0603
Only adding the first line still produce those errors.
In the header file WinUser.h, there is a part in which the constants of the second parameter of SetWindowLong() are defined.
// ...
#define GWL_WNDPROC (-4)
#define GWL_HINSTANCE (-6)
#define GWL_HWNDPARENT (-8)
#define GWL_STYLE (-16)
#define GWL_EXSTYLE (-20)
#define GWL_USERDATA (-21)
#define GWL_ID (-12)
#ifdef _WIN64
#undef GWL_WNDPROC
#undef GWL_HINSTANCE
#undef GWL_HWNDPARENT
#undef GWL_USERDATA
#endif /* _WIN64 */
#define GWLP_WNDPROC (-4)
#define GWLP_HINSTANCE (-6)
#define GWLP_HWNDPARENT (-8)
#define GWLP_USERDATA (-21)
#define GWLP_ID (-12)
// ...
But they are right after undefined if _WIN64 is defined; and it is defined in my 64-bit system.
As you see, there is also a GWLP_*** set of constants, but they are not documented in the page of SetWindowLong().
Why are these constants undefined in x64 systems?
What is the alternative way of calling SetWindowLong() in x64 systems?
My system:
OS: Windows 7 Ultimate x64 SP1
IDE: Visual Studio 2012 Ultimate Update 3
Some of the window data values (the ones that refer to "pointer sized" objects like the window procedure, for example) need to be 64 bit in an x64 build. The old SetWindowLong() and GetWindowLong() functions are limited to DWORD sized (32 bit) values for backwards compatibility, and Microsoft have introduced new versions, SetWindowLongPtr() and GetWindowLongPtr() that allow you to work with pointer-sized values (32 bit in a 32 bit build, and 64 bit in a 64 bit build).
These days it is recommended that you always use SetWindowLongPtr() and the GWLP_xxx constants, whether you are building for 32 or 64 bit, but in a 64 bit build you need to use the new functions and so the defines are #undefined to cause build errors that force you to fix your code.
As specified in <WinUser.h>
//If config is _WIN64 then use new versioned macro
#define GWLP_WNDPROC (-4)
#define GWLP_HINSTANCE (-6)
#define GWLP_HWNDPARENT (-8)
#define GWLP_USERDATA (-21)
#define GWLP_ID (-12)
//else for _WIN32
#undef GWL_WNDPROC
#undef GWL_HINSTANCE
#undef GWL_HWNDPARENT
#undef GWL_USERDATA
Also make sure you're NOT defining the following:
#define NOWINOFFSETS
which disables GWL_*, GCL_*, ie. GetWindowLongPtr and family, as well as associated routines.
I have a project that I compile and it gives me following errors as:
In file included from c:/acrobatxsdk/Adobe/Acrobat 10 SDK/Version 1/PluginSupport/Headers/API/PIMain.c:21:0:
c:/acrobatxsdk/Adobe/Acrobat 10 SDK/Version 1/PluginSupport/Headers/API/Environ.h:37:2: error: #error You must define the PLATFORM macro
c:/acrobatxsdk/Adobe/Acrobat 10 SDK/Version 1/PluginSupport/Headers/API/Environ.h:41:10: error: #include expects "FILENAME" or <FILENAME>
c:/acrobatxsdk/Adobe/Acrobat 10 SDK/Version 1/PluginSupport/Headers/API/Environ.h:52:2: error: #error PLATFORM failed to #define ACCB1
The PIMain.c looks like this :
#if WIN_PLATFORM
#include "WinCalls.h"
#elif MAC_PLATFORM
#include "MacCalls.h"
#elif UNIX_PLATFORM
#include "UnixCalls.h"
#else
#error platform not defined
#endif
I have come to know that the only amendment if required is to be made in Environ.h , can some one suggest how?
Environ.h is looking for the PLATFORM directive and there is a preprocessor or compile time flag to "throw" an error if you do not define it. See how the #error directive works here (MSDN link).
I found the code for Environ.h:
#ifndef PLATFORM
#ifdef WIN_ENV
#define PLATFORM "winpltfm.h"
#elif __OS2__
#define PLATFORM "os2pltfm.h"
#elif defined(unix) || defined(__unix)
#define PLATFORM "UnixPlatform.h"
#else
#error You must define the PLATFORM macro
#endif
#endif
You apparently are not running on a supported platform.