In my grammatic for boost::Spirit::Q in semantic action i need many (over 10) attribute placeholders. I try define BOOST_PHOENIX_ARG_LIMIT variable, as recommended in documentation, but it had no effect. If anybody know, how make it, say me, please. Version of boost is 1.48.0, compiler is MinGW GCC 4.4.0.
If you defined the macro in a source file try to pass the macro directly to the compiler command line, maybe it is not visible in all source files.
Related
I have to reset system date and time either on Linux, or on Windows.
How do I check OS without using ifdef, or if defined?
With CMake, you can conditionally add files to a target by using generator expressions. With that, you can isolate any platform-specific code in files, and use them in your build specification as follows.
add_executable(reset-time
$<$<PLATFORM_ID:Darwin>:resettime-macos.cpp>
$<$<PLATFORM_ID:Linux>:resettime-linux.cpp>
$<$<PLATFORM_ID:Windows>:resettime-windows.cpp>)
And as #eeroika pointed out in the comments, a good alternative is
add_executable(reset-time
resettime-$<LOWER_CASE:${CMAKE_SYSTEM_NAME}>.cpp)
as it requires not adjustment (of the CMakeLists.txt) when porting your project to a new system and you can catch a missing implementation file earlier, i.e., before linking.
You could set a global macro definition to the compiler based on which operating system you are compiling for. For example -D IS_WINDOWS=1. You could then use #if IS_WINDOWS instead of #ifdef. I don't know why this would be useful but it achieves what you asked.
I am a beginner with embedded programming and am using the IAR workbench for a project of mine using STM32F4Discovery. I am trying to compile an existing code and have a few errors at a few places regarding the bit definitions like the following:
Error[Pe020]: identifier "GPIO_PIN_SET" is undefined
Now, the GPIO_PIN_SET is defined in the file stm32f4xx_gpio_hal.h and is already included in my project. In order to resolve this issue when I looked up online, I have found this solution. However, I don't have the System tab in the General Options in my IAR Workbench. I have a full version of IAR Workbench and am not sure why the System tab is missing.
I also tried defining
#define ENABLE_BIT_DEFINITIONS
as stated in this link in my main.c file but to no avail.
Trying to set
#define STM32F4XX
#define USE_STDPERIPH_DRIVER
in the main.c file or defining the symbols STM32F4XX, USE_STDPERIPH_DRIVER in the Preprocessor tab in General Options as mentioned here also didn't help.
The solution could be very simple that I am probably overlooking but am not able to figure out what could I be missing. Any help would be appreciated
Including a header file in a "project" is not enough, you should actually include it (directly or indirectly) in the source file where the declarations are to be used. It would be that simple in any halfway sane development kit, but we are stuck with ST, and they force us doing it their way.
Include the "master" header in your main.c
#include "stm32f429i_discovery.h"
this would in turn include stm32f4xx_hal.h, which includes stm32f4xx_hal_conf.h, which included stm32f4xx_hal_gpio.h if the right #defines were there.
You might not have stm32f4xx_hal_conf.h
If that's the case, then copy Drivers\STM32F4xx_HAL_Driver\Inc\stm32f4xx_hal_conf_template.h into your project, rename it to stm32f4xx_hal_conf.h. Otherwise just make sure that #define HAL_GPIO_MODULE_ENABLED is not commented out.
Set the right #defines
New versions of STM32CubeF4 have been released since the tutorial you've linked was written, and a few things have apparently changed. As of version 1.6.0, define STM32F429xx in Preprocessor Options, and forget the ones above. Yes, I've noticed that there is a version 1.7.0 now, let's hope that compatibility lasts this time.
I have an Xcode 4.2 project which includes a target that cross-compiles for windows. I use custom build rules for C source files and C++ source files in that target, invoking i386-pc-mingw32-g++ via a custom script. For some reason, Xcode runs the custom script I have specified as being for C source files, even when compiling files with a .cpp extension. Why might this be? How can I get Xcode 4.2 to run the "C++ source files" script for my .cpp files?
I also have .c files in this project, and am hoping to use -std=c++11 flag when compiling c++ files to enable some c++11 features. If I compile the .c files with this flag, I end up with weird scoping issues on constants included from math.h that I have yet to really try and understand - I am hoping I can just get Xcode to run the correct script for my .cpp files.
Any ideas?
Update: I've been able to get Xcode to run the correct scripts. To do this, I had to change the Process drop-down menu selections from "C source files" and "C++ source files" both to "Source files with names matching:" and then manually enter *.c and *.cpp in the provided text field. Now I have to figure out why I'm getting an M_PI was not declared in this scope error message where I wasn't before - maybe a different version of math.h is being used with the -std=c++11 flag which either doesn't include the M_PI constant or provides it under a different namespace?
Update: Continuing to work on this - it appears the M_PI value I was using from math.h is actually a macro which is only #define'd if __STRICT_ANSI__ has not been defined. Apparently switching to c++11 by using the -std=c++11 compiler flag has caused this __STRICT_ANSI__ macro to be defined, and thus the M_PI macro I was previously using isn't there. I suppose it's better to just define my own pi constants than to mess with the declaration of this __STRICT_ANSI__ macro, but I'll probably dig into that a bit just to clarify why it is being declared now that I'm using the c++11 flag.
Update: I found this post How can I make C++0x and __STRICT_ANSI__ get along?, which just suggests undefining the 'STRICT_ANSI' macro right after the '-std=c++11' flag (or rather, the equivalent '-std=c++0x' flag. While this seems sketchy, no one has posted encountering any problems because of it and it appears to work just fine for me as well in this case. Gcc documentation on this macro is located here: http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html, with the following relevant statement:
The macro STRICT_ANSI is predefined when the -ansi option is used. Some header files may notice this macro and refrain from declaring certain functions or defining certain macros that the ISO standard doesn't call for; this is to avoid interfering with any programs that might use these names for other things.
Still not sure why the '-std=c++11' flag causes this to be defined when it isn't by default (which would be '-std=c++98', apparently).
If you want C++11 support without ANSI mode, use -std=gnu++11 instead of std=c++11.
My code is linking against several other libraries that are also developed at my company, one of these libraries is redefining several values from errno.h, I would like to be able to fix this, however I am having trouble finding the exact file that is redefining these values, I am want to know if there is a way to make the compiler tell me when a file has defined a particular value.
You can probably do it by adding -include errno.h to the command line that builds the library in question. Here's a quick example. I have a C program called "file.c":
#define ESRCH 8
That's it - then I compile with:
cc -c -include errno.h file.c
And presto, a compiler warning:
file.c:1:1: warning: "ESRCH" redefined
In file included from /usr/include/errno.h:23,
from <command-line>:0:
/usr/include/sys/errno.h:84:1: warning: this is the location of the previous definition
That will tell you where your bad definitions are.
Have you tried searching with grep?
If you don't want to search through all your headers for the particular #define, you could use
#undef YOUR_MANIFEST_CONSTANT
after each #include in your source module and then start removing them from the bottom up and see where your definitions come from.
Also, your compiler may tell you that a #define has been redefined. Turn all your warnings on.
With GCC I did something similar with:
g++ input.cc -dD -E > cpp.out
-dD tells cpp to print all defines where they were defined. And in the cpp output there are also markers for the include file names and the line numbers.
It is possible that some environments, I'm thinking IDE's here, have configuration options tied into the "project settings" rather than using a configuration header. If you work with a lot of other developers in a place where this behavior is NOT frowned on then you might also check your tool settings.
Most compilers will tell you where the problem is, you have to look and think about what the diagnostic notification is telling you.
Short of that, grep/findstr on *nix/Windows is your friend.
If that yields nothing then check for tool settings in your build system.
Some IDE's will jump to the correct location if you right click on the usage and select 'go to definition'.
Another option if you're really stuck is a command line option on the compiler. Most compilers have an option to output the assembler they generate when compiling C++ code.
You can view this assembler (which has comments letting you know the relative line number in the C++ source file). You don't have to understand the assembler but you can see what value was used and what files and definitions were included when the compiler ran. Check your compiler's documentation for the exact option to use
I learned that compiler will expand macros while compiling. Templates are also expanded at the compile time. Is there any way to see this expanded code? I am compiling using Visual Studio 2008.
any thoughts?
The VC++ compiler (cl.exe) supports a few command line switches for this:
/E preprocess to stdout
/P preprocess to file
/EP preproscess to stdout with no #lines
Additional command-line switches can be added in your project properties. In my version (VC2005), Configuration Options -> C/C++ -> Command Line -> Additional Options
The compiler doesn't actually do any of the macro expansion. That is the task of the pre-processor. It all appears as one step, but the compiler actually forks out to a separate pre-processor tasks and traps the output for you.
Templates are not "expanded" at compile time. They are instantiated on use during compile. The difference is that the compiler immediately generates object code for the template; there's no intermediate source code that comes out. You can't look at the instantiated template code as source, it's dumped out as assembly when it's needed.
If you have GCC you can also call the pre-processor directly using 'cpp' with the right arguments (mostly include paths and command line macro definitions). Others have answered for MSVC.
Note that /E in VC++ only expands preprocessor statements (that is, #include, #ifdef, #define etc.)
I am not aware of any modern compiler that allows to expand templates.
To emit the preprocessed code, call cpp directly of use the -E option in gcc and related compilers; I'm sure other compilers or suites have similar things (indeed as per the other answer it's /E or /P in VC++).
Not sure about outputting instantiated templates. That's much harder to do, I think, since it's actually part of compilation rather than preprocessing (at least in modern compilers, since the original cfront version which was a c++-to-c translator, if I recall correctly).
It's easy to add an option to compilers to show the output after macro substitution. That's defined as a simple text substitution option anyway. Many compilers implement this as a separate stage, sometimes even handled as a separate tool. In any case, the result of the macro substitution is a collection of Translation Units in text form.
Templates, on the other hand, are compiled. There are multiple stages to this. Names are resolved twice, for instance. In either stage, the compiler would store the result of the name lookup. That's a table entry. How would you show that in text form? There's no trivial C++ expression for that.