I'm looking for a standalone C++ preprocessor. I'll use with another language, so there's no point in running through a full fledged compiler, but it's a very limited script language, so the #define and #if and other directives will help me a lot.
For example, I'd be writing a file like this:
#define DEBUG
do some stuff
#ifdef DEBUG
show a message box or whatever
#endif
do some more stuff
I found something which fits my needs, mcpp.
It's a simple to use preprocessor and supports output to other languages thanks to a command line switch.
How about the GNU C preprocessor?
You can also take a look into M4 preprocessor if you want some processing power greater than C/C++ preprocessor has. For example - M4 supports recursive macros, which isn't supported by C/C++ macro processor.
Related
I'm compiling c++ to web assembly using clang --target=wasm32 --no-standard-libraries. Is there a way to convince clang to generate sqrt? It's not finding <math.h> with this target.
Do you already tried to compile without the flag --no-standard-libraries? If you remove it, the clang probably will find math.h library (because its a standard library).
This is because wasm32-unknown-unknown is a completely barebones targets in Clang, and doesn't have any standard library - that is, no math.h, no I/O functions, not even memcpy.
However, you can usually get away with using --target wasm32-wasi + WASI SDK instead: https://github.com/WebAssembly/wasi-sdk
It includes the whole standard library, including even functions for interacting with the filesystem via the WASI standard in compatible environments.
If your code doesn't depend on filesystem / clock / other I/O, then you can safely use WASI-SDK to get math.h, memcpy, malloc and other standard functions, and the resulting WebAssembly will be compatible with any non-WASI environments as well.
I'd like to convert a CMake-based C++ library to bazel.
As part of the current CMake project, I'm using a libclang-based code generator that parses C++ headers and generates C++ code from the parsed AST. In order to do that, I need the actual compiler flags used to build the cc_library the header is part of. The flags are passed to the code generation tool so it can use clang's preprocessor.
Is there any way I could access the compiler flags used to build a dependency from a skylark- or gen_rule rule? I'm particularly interested in the include paths and defines.
We're working on it. Well, not right now, but will soon. You might want to subscribe to the corresponding issue, and maybe describe your requirements there so we take them into account when designing the API.
Recently I enabled /W4 warnings (MSVC) to clean up a bit in my project and noticed that GLM uses non-standard compiler extension guarded by #define GLM_HAS_ANONYMOUS_UNION, that causes a very long warning spew.
There seems to be compiler feature detection mechanism, but I can't disable compiler extensions entirely because of Windows SDK dependencies and the /Za is discouraged as buggy anyway. So what is the proper way to disable that particular thing in GLM?
I could slap an #undef everywhere i use GLM but is there a "proper" place to configure these things, like a separate config file or something? I'm upgrading GLM from time to time so I wouldn't want to modify that define in the GLM's code.
I ran into the same problem as you.
GLM will try to use all capabilities of your compiler and if it detects VS it will use nonstandard extensions in order to do some fancy things.
If you want these non-standard things to go away (e.g. nameless unions/structs)
you can switch GLM into standard mode by using
#define GLM_FORCE_CXX11
just before you include any glm header.
I plugged this info from the manual at:
http://glm.g-truc.net/0.9.7/glm-0.9.7.pdf
Alternatively you can look into disabling this very specific warning via pragma warning push
#pragma warning(push)
#pragma warning(disable:4201) // suppress even more warnings about nameless structs
#include<glm/glm.hpp>
#pragma warning pop
more info at https://msdn.microsoft.com/en-us/library/aa273936(v=vs.60).aspx
I'm wanting to write some compile-time code (i.e. code that is run when the project is compiled). This is used in other languages (e.g. Java) to write code generators (e.g. Dagger 2).
Is this possible in Swift? If so how? It is rather important for what I'm attempting to do.
Your question is very vague. There are multiple reasons for writing compile-time code, and it all depends on what you want to do.
If you want to write conditional code that only runs based on certain compile-time directives, use
#if build configuration
statements
#else
statements
#endif
If you want to generate code like a preprocessor would do in macros to reduce code duplication, then you should simply change your mindset and use swift functions and generics that will achieve the same result, only better. (Simple macros like #define xxx ... are replaced by let xxx = ...).
Finally, if you want to generate huge amounts of code then Swift isn't the language for you, you should use a dedicated code generator or some scripting language. For example, if you're looking to generate code for a state machine, use dedicated tools for that task that take as input UML. Obviously you'll have a hard time today finding tools that output Swift code (least of which being that Swift itself is a moving target), but that'll change over time.
While discussing OpenCOBOL being utilized for FastCGI, I posted that replacing
#include <stdio.h>
with
#include <fcgi_stdio.h>
should exhibit no behaviour change for the vast majority of programs that don't care to call
FCGI_Accept()
Did I lie? Are there issues to consider? I'll admit to having not gone over sources yet, only docs from the website.
EDIT: 2013-03-08
I've done some experiments, and the statement is proving positive, but lack sufficient evidence to advertise the statement as true. I'd still appreciate any insider information.
As fcgi_stdio.h is redefining many stdio symbols to its own set of FCGI_* symbols, there will with certanity be some differences. Fastcgi also offers the possibility to #define NO_FCGI_DEFINES though, which lets you use both sets - although you'd have to be explicitly specifying the FCGI_ prefix.
I was just thinking about adding a way to determine which set is to use at runtime to be able to use the same binaries online and from cli, but thinking further about it I'll rather go with two make targets.
Also, compiling with libfcgi-dev v2.4.0 I seem to run into blank output in conjunction with -ldl / dlopen() although both binaries link to the same libfcgi.so.0...
--
tl;dr if you want to use dlopen() and see the output on stdout/stderr, don't #include <fcgi_stdio.h> (without defining NO_FCGI_DEFINES)