Can i use something like #ifdef in FLEX and/or BISON source code? I would want to control what options my scanner recognizes depending on different compilation parameters.
Also, is there a way to use multiple sources at the same time? (for example scanner1.lex and scanner2.lex to be combined into lex.yy.c)
Neither flex nor bison come with a preprocessor, and it would be unwise to use the C preprocessor, since your source files are likely to contain C preprocessor directives intended to be passed through to the generated code.
But nothing stops you from writing your own preprocessor, or using a macro language like m4. (m4 must be available because both flex and bison depend on it.)
Related
I'm working on a CMake-based project that contains both C++ and CUDA source files, and has some headers meant to be included by both languages.
For these header files, I'd like to see the result of highlighting and syntax checking as close as possible to what NVCC, the CUDA compiler, would see, so for example, I'd like to have the preprocessor symbol __CUDACC__ be defined.
It's important to me that CMake does not have such a symbol defined, because it's really an internal symbol of the NVCC toolchain that I need for syntax-checking purposes.
I've tried "Tools->C++->Additional preprocessor directives" and it seems to have no effect. I've also tried a file named CMakeLists.txt.config which seems to have no effect either.
I'd love a suggestion for this.
To reiterate, I'm looking for a way to set a define (CPP symbol) visible to to the syntax-checking system only.
After further digging I found an attribute specific to the Clang analyzer that is defined during the analysis performed for syntax checking but not during compilation.
Note that this is purely because my project compiles with GCC, while QT Creator's syntax checking runs through Clang.
// GCC and NVCC don't have __has_feature(), so we provide a fallback
#ifndef __has_feature
# define __has_feature(x) 0
#endif
#if __has_feature(attribute_analyzer_noreturn)
# define IN_CLANG_ANALYZER 1
#else
# define IN_CLANG_ANALYZER 0
#endif
This allows a clumsy hack as follows, which may or may not be useful, depending on one's needs. Pretty much the idea is that much like you'd
have Clang observe your code even if you compile with GCC, this achieves
something similar for files inteded to be used with NVCC.
#if IN_CLANG_ANALYZER and !defined(__CUDACC__)
# define __CUDACC__
# include <cuda_device_runtime_api.h>
# include <optix_device.h>
#endif
However the substantial problem remains that when compiling with Clang, all the above falls flat on its face, because clang++, the compiler, also defines the same feature as enabled.
What's needed to fix this is some kind of macro defined in the analyzer but not in Clang, and so far I've found none like this.
At first I had hoped __clang_analyzer__ would fit this need,
but according to my version of Qt Creator (6.0.2) the macro is not defined
during syntax checking, so we're back to square one.
According to the documentation, setting CXX_STANDARD_REQUIRED to ON prohibits the build system from using older C++ standards then the one requested by CXX_STANDARD.
But this leads to "interesting" problems when combined with the WriteCompilerDetectionHeader module. e.g. when offering some form of "forward compatibility":
set(CMAKE_CXX_STANDARD 11) and testing for cxx_relaxed_constexpr, then conditionally defining a macro that expands to constexpr leads to compilation errors on GCC 6.3.0 as the requirements of CXX_STANDARD and the usage of the macro are conflicting (the feature header using the actual feature set of the compiler, not the one offered by the compiler when requiring C++11).
Is there any way to specifying a required minimum C++ standard, without prohibiting more recent standards (e.g. C++ 11 or later)? The only workaround I can currently think about would be to not set CXX_STANDARD and CXX_STANDARD_REQUIRED at all and just "informally" require a minimum version of C++...
No, there is no way to do this easily. While you could extend CMake to continuously compile objects up-to (or down-to) a specific standard, this would take quite a lot of effort. There ways to possibly do what you want depending on your circumstances.
Use non-conflicting macros. Using your example, use #define MYCONSTEXPR ... instead of #define constexpr ...
Use larger conditional blocks based on the standard
Is your project mostly one standard, but have a few files that need a different one? use CMake's set_source_files_properties() to set a new CXX_STANDARD or COMPILE_FLAGS.
I have an application that uses Verilog and C (SystemC to be precise). I wanted to see if there was a way to have a common header file that can be used across the entire application ?
Such that:
#define FOO 4
doesnt have to be repeated in another verilog file
`define FOO 4
Some simulators will let you define macros from the command line during compile and pass the definition to SystemC and Verilog. Check with your simulators manual, it should look something like +define+FOO=4 of -defineall FOO=4 if it is supported.
The other approach is to create a script to that generates a converted header for you. This way you only maintain one file. This approach is better if you also want to share struct, typedef, and enum between SystemVerilog and SystemC.
I think they are different languages. It is hard to make common file to be used directly. But you can have a common source and use script to generate the header files for you.
I have a multi-platform project, running on Windows, Linux and iOS right now, but I have stumbled upon a undesirable problem with Objective-C.
I have, unfortunately, chose the name exp for one of my types (expressions, pretty reasonable given the number of occurrences in my code), but Objective-C somehow includes the math.h header by default, creating a name-clash.
I tried to comment out everything in the .pch (the prefix file included by default before every source file), and exp is still flagged as redefinition.
Does anybody know how to not include math.h in a source file inside Objective-C project?
Objective-C does not have a formal specification, but it inherits features from C. In C, programs should not use identifiers from the standard headers, even if they do not include those headers. So, you should not use “exp” for your own identifiers.
If you insist upon using “exp”, you might be able to work around the issue with a preprocessor statement:
#define exp MyExp
This will allow you to write “exp” in your source code as if it were one of your identifiers. Since the preprocessor will change it to “MyExp”, the compiler will see “MyExp” as the identifier and will not complain.
This will cause a number of problems, such as the identifier showing up as “MyExp” in object code information and in debugging tools and causing inability to use exp from math.h in the future.
To support multiple platforms in C/C++, one would use the preprocessor to enable conditional compiles. E.g.,
#ifdef _WIN32
#include <windows.h>
#endif
How can you do this in Ada? Does Ada have a preprocessor?
The answer to your question is no, Ada does not have a pre-processor that is built into the language. That means each compiler may or may not have one and there is not "uniform" syntax for pre-processing and things like conditional compilation. This was intentional: it's considered "harmful" to the Ada ethos.
There are almost always ways around a lack of a preprocessor but often times the solution can be a little cumbersome. For example, you can declare the platform specific functions as 'separate' and then use build-tools to compile the correct one (either a project system, using pragma body replacement, or a very simple directory system... put all the windows files in /windows/ and all the linux files in /linux/ and include the appropriate directory for the platform).
All that being said, GNAT realized that sometimes you need a preprocessor and has created gnatprep. It should work regardless of the compiler (but you will need to insert it into your build process). Similarly, for simple things (like conditional compilation) you can probably just use the c pre-processor or even roll your own very simple one.
AdaCore provides the gnatprep preprocessor, which is specialized for Ada. They state that gnatprep "does not depend on any special GNAT features", so it sounds as though it should work with non-GNAT Ada compilers. Their User Guide also provides some conditional compilation advice.
I have been on a project where m4 was used as well, with the Ada spec and body files suffixed as ".m4s" and ".m4b", respectively.
My preference is really to avoid preprocessing altogether, and just use specialized bodies, setting up CM and the build process to manage them.
No but the CPP preprocessor or m4 can be called on any file on the command line or using a building tool like make or ant. I suggest calling your .ada file something else. I have done this for some time on java files. I call the java file .m4 and use a make rule to create the .java and then build it in the normal way.
I hope that helps.
Yes, it has.
If you are using GNAT compiler, you can use gnatprep for doing the preprocessing, or if you use GNAT Programming Studio you can configure your project file to define some conditional compilation switches like
#if SOMESWITCH then
-- Your code here is executed only if the switch SOMESWITCH is active in your build configuration
#end if;
In this case you can use gnatmake or gprbuild so you don't have to run gnatprep by hand.
That's very useful, for example, when you need to compile the same code for several different OS's using even different cross-compilers.
Some old Ada1983-era compilers have a package called a.app that utilized a #-prefixed subset of Ada (interpreted at build-time) as a preprocessing language for generating Ada (to be then translated to machine code at compile-time). Rational's Verdix Ada Development System (VADS) appears to be the progenitor of a.app among several Ada compilers. Sun Microsystems, for example, derived the Ada SPARCompiler from VADS and thus also had a.app. This is not unlike the use of PL/I as the preprocessor of PL/I, which IBM did.
Chapter 2 is some documentation of what a.app looks like: http://dlc.sun.com/pdf/802-3641/802-3641.pdf
No, it does not.
If you really want one, there are ways to get one (Use C's, use a stand-alone one, etc.) However I'd argue against it. It was a purposeful design decision to not have one. The whole idea of a preprocessor is very un-Ada.
Most of what C's preprocessor is used for can be accomplished in Ada in other more reliable ways. The only major exception is in making minor changes to a source file for cross-platform support. Given how much this gets abused in a typical cross-platform C program, I'm still happy there's no support for it in Ada. Very few C/C++ developers can control themselves enough to keep the changes "minor". The result may work, but is often nearly impossible for a human to read.
The typical Ada way to accomplish this would be to put the different code in different files and use your build system to somehow choose between them at compile time. Make is plenty powerful enough to help you do this.