#define SOMETHING
William Labbett

hi again,

A question I've been wanting to ask is this :-

I understand that

#define TWELVE 12

means that occurences of TWELVE in the source file are replaced with 12.

.......but I see in lots of code with

#define MAIN_H
#define SOMETHING

with no replacement text which confuses me.

are these types of define only relevant to be used with

#ifndef ?

any kind of clarification would be much appreciated.

X-G

Not only, but that would be their main use. They are replaced with nothing if used normally.

OnlineCop

Also, sometimes it's important to #define something away, which is also very important in programming.

For example, Windows may have some sort of construct, like __declspec that Linux and Mac just don't use. The preprocessor macro can then be used to either #define a macro to be something, or you can just #define it completely away:

#ifdef WIN32
#define DECLSPEC __declspec
#else
#define DECLSPEC
#endif

...later...

DECLSPEC void myfunction() {...}

So on Linux, the line above would look like:

void myfunction() {...}

while on Windows, it would be:

__declspec void myfunction() {...}

William Labbett

okay, so a statement like

#ifndef SOME_HEADER

basically is true

if there was a #define SOME_HEADER statement before it, or false if not.

Is that right ?

kazzmir

Yes.

William Labbett

thanks all,

regarding this

__declspec void myfunction() {...}

I've seen a lot of code with something before a type but the only ones I understand are the ones like unsigned, long, const, etc..

I noticed the allegro code has a lot of these but I don't understand their purpose, what they mean or how to implement them.

There doesn't seem to be much help on them in the K&R C book I have.

kazzmir

There are lots of function modifiers you can add that are not part of pure C (except for maybe inline, I dunno). They are extensions added by your compiler (msvc, gcc, etc.)

__declspec refers to the way arguments are placed on the stack when the function is called. You can either do first argument on the bottom of the stack or first argument on the top of the stack. I forget which __declspec is, but thats the windows way IIRC.

So basically you need to add __declspec if you are trying to call a windows function. On unix it uses the other way so you can either explicitly say the type (I forget what it is) or just leave it off and gcc will default to the unix way.

msvc probably defaults to __declspec, I imagine.

Kitty Cat

__declspec is like GCC's __attribute__. It specifies special declaration options. Eg, __declspec(dllimport) tells the compiler that the function is imported from a DLL and not statically linked (it needs to know so it can add a special symbol prefix and tie it to a specific DLL at link-time).

William Labbett

right, thanks.

kazzmir

Oh yea I was confused, ignore most of what I said and read this instead http://unixwiz.net/techtips/win32-callconv.html

X-G

K&R C book

K&R? Really? I would update my references if I was you. K&R was written in 1978 and hasn't been valid for decades.

William Labbett

Okay, I'll take a look in a book shop next time I go into Norwich.

OnlineCop

[rant]
Okay, first of all, don't derail this based on my puny reference to __declspec. I've never even used it myself. Ever. I don't even know how or what I'd use it for. I'm just not that good of a programmer yet.

I was just using it to answer the OP.
[/rant]

#SelectExpand
1// Before this file had ever been #include'd, this had NOT been #define'd 2#ifndef _MY_HEADER_GUARD_ 3 4// NOW it's defined 5#define _MY_HEADER_GUARD_ 6 7// your code here... 8 9#endif

Now if you try to #include "that_header_file.h" more than one time, your compiler will see that, oops, yes, it's already been "defined" and won't re-include it.

Conversely, Windows declares "BITMAP" in "windows.h". So if you compile allegro for Windows, we #include "winalleg.h", which redefines all Allegro BITMAPs to something like AL_BITMAP using #defines, making Allegro play nice with Windows.

Evert
X-G said:

K&R was written in 1978 and hasn't been valid for decades.

One presumes he's referring to the second edition. That's still missing the latest additions (from C99), but other than that it's still both valid and relevant because C hasn't changed that much.

William Labbett

Yes, I have the second edition. I like it because they know what they're talking about and it's not a big book. I might aswell use the web for C99 things.

Thread #601312. Printed from Allegro.cc