Why would a #define statement in a .pch not be recognized by .mm files?
Results in "use of undeclared identifier" and "not declared in this scope" when attempting to reference the macro.
Pch looks like this:
#import <Availability.h>
#ifndef __IPHONE_3_0
#warning "This project uses features only available in iPhone SDK 3.0 and later."
#endif
#ifdef __OBJC__
#import <Foundation/Foundation.h>
#import <UIKit/UIKit.h>
#endif
#ifdef DEBUG
#define dNSLog(...) NSLog(#"%s %#", __PRETTY_FUNCTION__, [NSString stringWithFormat:__VA_ARGS__])
#else
#define dNSLog(format, ...)
#endif
I had the same problem, cleaning was not solving it.
After closing and restarting Xcode 4 everything was fine.
If that can help someone...
Turns out Xcode 4 wasn't actually cleaning the build. :(
Related
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
When testing for features in Visual Studio, I found this weird behaviour:
#ifndef __cpp_constexpr
#error Opposite day! //Compiler error
#endif
#define test_macro
#ifndef test_macro
#error But only for feature macros? //No compiler error
#endif
int main() {}
__cpp_constexpr is definitely defined, I used it in the actual program.
From my testing, it seems that with feature macros #ifndef behaves like #ifdef
and vice versa.
Is this a Visual Studio bug, or am I missing something?
Compiled in VS 2017, Visual C++14 or later, with C++17 standard enabled.
P.S. Intellisense is working as intended, it's only the compiler.
You are using incorrect pre-defined macro and pre-proc code. Next code can help:
#if defined(__GNUG__) && (__cplusplus > 201103L)
# define HAS_CONSTEXPR
#elif defined(_MSC_VER) && (_MSC_FULL_VER >= 190024210)
# define HAS_CONSTEXPR
#endif // __GNUG__
#ifndef HAS_CONSTEXPR
# error Opposite day! //Compiler error
#else
# define test_macro
# ifndef test_macro // useless by why not ?
# error But only for feature macros? //No compiler error
# endif
#endif
Suggesting to use boost config library. It is cross compiler, an you can solve it like this:
#ifdef BOOST_NO_CXX11_CONSTEXPR
# error Opposite day! //Compiler error
#endif
And it is going to work for all compilers supported by boost (according to the boost license, you can exam the source code and replicate is in you project)
first of all I have to mention that I'm new to c++ but within my course of studies I have gained some experiences with programming.
Currently, I'm working on a plugin for a datastream between vicon blade 1.7 and unreal engine 4.4.3. This should be done by using the Vicon Datastream SDK v 1.4 which contains a header file, a library and a .dll file.
Right now, I'm having problems with compiling my basic plugin.
The Vicon DataStream SDK was build within an older version of visual studio than 2010. So I want to know if there is any possibility to go on working with the vicon sdk in visual studio 2013? Should I force the sdk to use the latest .dll in visual studio and if so how do I do that?
I already tried to go on working with the sdk ignoring the problem I've mentioned before.
When I built the project without changing the header file of the sdk I'm getting this error:
Error 2 error C2059: syntax error : 'constant'
Here are the affected rows:
#ifdef WIN32
#ifdef _EXPORTING
#define CLASS_DECLSPEC __declspec(dllexport)
#else
#define CLASS_DECLSPEC __declspec(dllimport)
#endif // _EXPORTING
#elif defined( __GNUC__ )
#if __GNUC__ < 4
#error gcc 4 is required.
#endif
#define CLASS_DECLSPEC __attribute__((visibility("default")))
#else
#define CLASS_DECLSPEC
#endif
#include <string>
namespace ViconDataStreamSDK
{
namespace CPP
{
...
}
}
If I redefine the second namespace to 'UCPP' I'm getting a huge list of errors like this one:
Error 2 error LNK2019: unresolved external symbol
"__declspec(dllimport) public: __cdecl
ViconDataStreamSDK::UCPP::Client::Client(void)"
I think it's because CPP is already defined in unreal engine but because of the dependency of the header file to the .dll file in the sdk the definition of the namespace is unchangeable in the sdk.
Is that expectation correct or am I on the wrong track?
I had similar problems with the name space. To fix that I did this in my UE4 Plugin header file before including the Vicon DataStreamSDK
#define UCPP CPP
#undef CPP
#include <Client.h> //Vicon DataStreamSDK
.....
At the end of this file I redifined the CPP macro
#define CPP PCPP
This compiles and works fine with no problems
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 am compiling a quite a big project using VxWorks6.8 C++ compiler. I am getting following warning
warning: extra tokens at end of #endif directive
#ifndef _OM_NO_IOSTREAM
#ifdef WIN32
#ifndef USE_IOSTREAM
#define USE_IOSTREAM
#endif USE_IOSTREAM
#endif WIN32
I am getting a quite a lot of these warnings.
Why i am getting these warnings and from C++ standard point of
view?
What is the good reason why compiler is warning for this?
What is the best way to fix this?
Thanks
#endif USE_IOSTREAM
#endif WIN32
Should be:
#endif // USE_IOSTREAM
#endif // WIN32
endif doesn't take any arguments. Such comments are placed only for better readability.
You also missed closing #endif // _OM_NO_IOSTREAM at the end.
Because you can't have anything after #endif
Also, you're missing an endif.
#ifndef _OM_NO_IOSTREAM
#ifdef WIN32
#ifndef USE_IOSTREAM
#define USE_IOSTREAM
#endif
#endif
#endif
#endif USE_IOSTREAM
#endif WIN32
// ^^^^^^^^^^^^ Compiler is warning about these extra tokens after endif directive.
There is no need of any identifier after #endif. The way to suppress those warnings is to remove them.
Normally you don't put text behind the #endif. (And you are missing an #endif for OM_NO_IOSTREAM)
http://msdn.microsoft.com/en-us/library/ew2hz0yd%28v=vs.80%29.aspx