I'm compiling for an embedded target and my compiler understands some non-standard macros. I want to define some "stub" macros for the benefit of eclipse (so that it doesn't pester me with spurious warnings).
I want something like:
#ifdef ECLIPSE_ENVIRONMENT
void __WFI_STUB(void) {}
#define __WFI __WFI_STUB
#endif
So that in my code (which compiles fine),
__WFI();
Eclipse won't freak out about an unresolved function.
Ah.
#ifdef __CDT_PARSER__
// do stuff
#endif
Related
I have project that was created in another IDE that is build for a specific microcontroler. In the code faris used quite often and it is comprehended by the IDE and compiler.
I would like to use eclipse to edit the code, because it is more convinient to use. But it generates a lot of warnings and errors in the editor because he can not resolve the far.
I could create a macro #define far, but I would have to remove it when I want to compile the code. I don't compile with eclipse, because getting the compiler to work there is cumbersome and might introduce problems.
So is there a possibility that eclipse itself can handle the far for its syntax check?
Another approach that involves modifying your code rather than the project settings would be:
#ifdef __CDT_PARSER__
#define far
#endif
__CDT_PARSER__ is a macro that is automatically defined by CDT's parser when it processes your code, but not by any compiler.
After I searched a bit more I found an answer here:
https://www.eclipse.org/forums/index.php/t/72375/
Go to the menu:
Project -> Properties -> C/C++ General -> Path and Symbols ->
Symbols
and add a Symbol called far with the value /* */.
I just left the value empty and it worked.
I added the line extern "C" void perlinTest(void); to a C++ header along with the include of the c header file hoping that was all I needed but the compiler complains:
Undefined symbols for architecture i386:
"perlinTest()", referenced from:
CreateRenderer3(IResourceManager*) in Renderer.o
Your C++ code needs to be aware that the function is a C function. To do so, you need to declare it this way:
extern "C" [prototype];
A realistic example for your situation would be:
extern "C" void perlinTest();
The reason for this is that C++ function names are mangled to something that tells about the types of the parameters. At the lowest level, this is what allows overloading: it never really is legal to have two visible symbols that share the same name, so C++ allows them by embedding markers that indicate the types of the parameters in the function names. For instance, void perlinTest() gets mangled as _Z10perlinTestv on my Lion box with g++ (and probably clang++), though this is ABI-specific and will not necessarily be the same on other platforms.
However, C doesn't support overloading, and functions aren't subject to name mangling, so when your C++ code tries to call one, it needs to know that it must not use a mangled name. This is what extern "C" tells the compiler.
If your header files need to be readable from both C and C++, the common practice is to wrap them in an extern "C" block (extern "C" { /* declarations */ }) itself wrapped in an #ifdef __cplusplus preprocessor directive (so the C code doesn't see the extern "C" code).
#ifdef __cplusplus
extern "C" {
#endif
/* header body */
#ifdef __cplusplus
}
#endif
If it is not a library, you do not need any extern C. Iwould be turning to the .c file extensions and how your compiler is configured to recognize it (looks like not as .c code)
Have you actually implemented void perlinTest(void) anywhere?
Initially, you'll likely be able to merely declare the function without actually having to implement it. If none of your other classes/objects actually call perlinTest(), Xcode will gladly build and run your app, and not issue any errors. Since perlinTest() isn't actually referenced from anywhere, it doesn't care that the function isn't actually implemented.
As soon as you attempt to call perlinTest() from one of your other classes (like from CreateRenderer3(IResourceManager*) in Renderer.o), the linker will want to make sure that symbol can be resolved, and if you haven't actually implemented a barebones definition of it (see below), then you'll likely get an error like the one you got.
A minimal implementation like the following should prevent the linking error:
void perlinTest(void) {
}
One trick you can use to debug this is to introduce an intentional error in your perlinTest() function. Then build your app and see if the compiler reports the error. If the app compiles anyway, then your problem is that the file that has this function is not part of the target you are building.
Also note that the error that you pasted is for a i386 architecture, so it can't be iPhone. You are probably building for the iPhone simulator instead.
Edit: next step would be to check that the link command issued by Xcode includes the .o that has the C function. If it does, then you should dump the contents of the .o file with the nm utility, to see what the function name looks like in the .o.
I have added some debugging code to my app which I want to call only when needed. I remember there is some kind of IFDEF that can be used to conditionally include code into a source file.
For example I might have something like this:
IFDEF kDebugEnabled == YES {
// some debugging code here
}
And then this piece of code is only compiled into the binary if that kDebugEnabled is YES.
How can I do something like this?
Please note: I don't want to use the project compiler flag settings. I just want to define a BOOL (or something that serves the purpose just as well) which is true or false and then just easily set it in my App Delegate for example. I find it hard to navigate to the project compiler settings, searching for a flag and then setting it. I know there is a Debug flag which might be of use.
What you are looking for is:
#ifdef __YOURSYMBOL__
<conditional code>
#endif
You can programmatically define __YOURSYMBOL__ like this:
#define __YOURSYMBOL__
__YOURSYMBOL__ can be any string that makes sense to you to remember why you are including/excluding that code snippet.
The DEBUG constant is a special preprocessor constant that the compiler defines specifically for you when the code is built for debugging, so you can simply use it:
#ifdef DEBUG
<conditional code>
#endif
Take into account that this is the C-preprocessor, not C, nor Objective-C that you are using, so a test like kDebugEnabled == YES (where kDebugEnabled is an Objective-C variable) is simply not possible. You can define integer values for your constants, like this:
#define __LOG_LEVEL__ 3
and then test for it:
#if __LOG_LEVEL__ == 3
...
Endif
As far as I know, you can't have code in your classes that is not compiled into the final product without using compiler flags. However, using the DEBUG flag is a lot easier than you think. If you are using Xcode 4, it's set up for you by default.
#ifdef DEBUG
// Your debug-only code goes here
#endif // DEBUG
Xcode has, by default, two configurations, Debug and Release. When you use the debug build configuration, among other things, it sets the DEBUG compiler flag, which you can then use to conditionally compile code. No need to mess with compilation settings at all.
I need the code I am writing for a project to match some style guidelines. However the standard templates included with CDT don't match this style. Especially the layout of the header guards is not the way it should be. I had a look at the template and for my Eclipse it looks like this:
${filecomment}
#ifndef ${include_guard_symbol}
#define ${include_guard_symbol}
${typecomment}
${declarations}
#endif /* ${include_guard_symbol} */
So I am guessing the variable ${include_guard_symbol} is set somewhere in the CDT, but is it possible to change this setting without needing to modify the CDT itself?
On a slightly different, but related note:
Is it possible to add your own templates, so you just could add new files of other types (test-cases, specialized classes etc) using the normal new dialog for the project?
We've had a similar struggle on our project. One solution is to throw out ${include_guard_symbol} in the template all together, and define it yourself, possibly using some of the other predefined variables. Something like this:
${filecomment}
#ifndef MyProject_${file_base}_h
#define MyProject_${file_base}_h
${typecomment}
${declarations}
#endif /* MyProject_${file_base}_h */
So for a header file named inc/Foo.h, the include guard would be inserted like this:
#ifndef MyProject_Foo_h
#define MyProject_Foo_h
Unfortunately, there doesn't seem to be a way to customize much beyond that. For example, if I defined a class nested in a namespace, I might want to put the namespace as part of the include guard. I can't find a way to do that in eclipse, currently.
So in the Preferences dialog under C/C++ -> Code Style -> Code Templates you can modify the template to be closer to what you need, for example if you need the namespace in the guard, you can do something like.
${filecomment}
#ifndef ${namespace_name}_${include_guard_symbol}
#define ${namespace_name}_${include_guard_symbol}
${includes}
${namespace_begin}
${declarations}
${namespace_end}
#endif /* ${namespace_name}_${include_guard_symbol} */
I just found two piece of code
#if CONSOLE // defined by the console version using
ournamespace.FactoryInitializer;
#endif
and
#if _NET_1_1
log4net.Config.DOMConfigurator.ConfigureAndWatch(new System.IO.FileInfo(s) );
#else
log4net.Config.XmlConfigurator.ConfigureAndWatch(new System.IO.FileInfo(s) );
#endif
Can any one please tell me with a running sample( please provide a simple one) what is the significance of those code snippets and when and how to use those?
Thanks.
Sure. These refer to conditional compilation symbols which can be defined at compile-time and which control what code is actually built. Here's an example:
using System;
class Test
{
static void Main()
{
#if FOO
Console.WriteLine("FOO was defined");
#endif
#if BAR
Console.WriteLine("BAR was defined");
#endif
}
}
If you compile this with
csc Test.cs
It won't print anything. If you compile it with
csc Test.cs /D:FOO
then it will print "FOO was defined" - and obviously the same is true for BAR.
Note that these aren't the same as C++ macros - a symbol is either defined or not; it doesn't have a "replacement value" as such.
In Visual Studio, you specify which symbols should be defined in the Build tab of the project properties. Additionally, at the very start of the file you can explicitly define and undefine symbols:
#define FOO
#undef BAR
This can be important when calling methods decorated with ConditionalAttribute - such calls are ignored by the compiler if the appropriate symbol isn't defined. So if you wanted to make sure that all your Debug.Print calls came through even if you hadn't defined the DEBUG symbol for the rest of the project, you could use:
#define DEBUG
...
Debug.Print("Foo");
Personally, I don't use all this very much. Aside from anything else, it makes it easier to understand the code if you know that it will all be compiled and run at execution time.
EDIT: Just to clarify a little on terminology - #if, #line, #pragma etc are all preprocessor directives; FOO and BAR (in this case) are the conditional compilation symbols.
They're used for conditional compilation.
If CONSOLE (known as a conditional compilation symbol) is defined for the first example with #define CONSOLE, the code within #if CONSOLE and #endif will be compiled and built into the assembly, otherwise the compiler ignores the code within them.
Undefining a conditional compile symbol is via #undef e.g #undef CONSOLE. The language specification also states :
There is no requirement that
conditional compilation symbols be
explicitly declared before they are
referenced in pre-processing
expressions. Instead, undeclared
symbols are simply undefined and thus
have the value false.
Those are called preprocessor directives. Quote from the docs:
'#if' lets you begin a conditional directive,
testing a symbol or symbols
to see if they evaluate to true. If
they do evaluate to true, the compiler
evaluates all the code between the #if
and the next directive.
So basically when you compile your program with /define:symbol switch it will either evaluate the if statement or not. For example:
csc foo.cs /define:DEBUG
allows you to define the DEBUG directive and enter the #if DEBUG branch. Remember that contrary to the if statement those are purely compile time and the body of the else statement won't even be included in your compiled assembly.
Your project can have multiple configurations, the most common are Debug and Release.
In Debug mode you can output debug strings, do additional checking etc.
For example:
void a(int x){
#if DEBUG
System.Diagnostics.Debug.WriteLine("a("+x+")");
#endif
//Do stuff.
}
You can define directives project-wide in the project's properties and make debug/release builds, or you could make an application that uses different libraries for some output (OpenGL/XNA). Or as you have, #if _NET_1_1 checks if a symbol _NET_1_1 is defined, assuming that .NET FX 1.1 is used, and uses proper classes, so you can target multiple framework versions in multiple project configurations.