[karlan]

Having done 99% of my mud coding with circleMUD, I cannot speak for other code bases, but circle has a lot of macros in it. Now, personally I hate macros in general, they annoy me every time it comes time to debug, and since I learnt how to use inline functions before macros (I remained somehow ignorant of them for quite a while) I tend to use inline functions.

I guess I am generally curious about others opinions/preferences, I can definately see their uses.
Typing:
[code] if(EXIT(room, dir)) {.....[/quote]
is much quicker than
[code] if(world[room].dir_option[dir]) {.....[/quote]
but the same can be acheived with an inline function, and that is a very simple example, there are some multiline macros, that get really annoying as it is painful (particularly if you are lazy like me) to track down where in the macro the check is failing (given you know it should succeed)

Anyone?

[Tamsyn@zebedee.org]

I expect it's because the code® historically was in C, that doesn't support inline functions.

C++ has const to replace #define symbols (as opposed to 'functions' if you can call them that) and inline otherwise. The most obvious advantage is type safety.

One advantage of macros is that they can be conditionally compiled out of your exe - for example debugging code can be compiled out when building a 'release' exe.

Another is they support which (I think) is not the case with an inline function - it would report the number of the line where the inline function is defined, not where it is called from.

Another is that they can be used as shorthand for declaring a local variable. For example

#define FUNCTION_START(name) FunctionLogger(name);

which declares a local object of type FunctionLogger, initialised with the function name. This object could log to a file that the function has been entered, and its destructor can log to the file that its exiting. You can't do that with an inline function.

[Tamsyn@zebedee.org]

Hmm a couple of curious 'changes' to the above edit due to html i guess.

It should read 'they support "_ _ LINE _ _" (without the spaces)

and the ( r ) symbol should read like that.

Ho hum.

[Yui Unifex]

Inline functions, which weren't supported in C until the C99 standard (but your compiler definately supports them), are almost always preferable over macros. Macros may expand their arguments more than once, which can cause problems if you use an arithmetic operation on an argument. They're harder to debug, as the expanded code doesn't really exist at a place that the compiler can report problems to you unambiguously. Inline functions can catch type safety issues earlier because you have to explicitly declare the types of the arguments. Finally, multiline macros are a bad idea in general: They have a completely different syntax for "declaration" of a macro function because the entire body has to fit on one line, thus requiring the usage of \. This is error prone and harder to maintain than the normal function syntax.

Macros and inlines should be separated from each other, IMO. Macros are code generators, whereas inline functions are code. Macros allow you to do many things that inlines can not, like reduce the amount of work needed to create repetitive functions. So use the two concepts accordingly and there shouldn't be any confusion.

[karlan]

I still use macros (in the MUD code) as an alias to globals *shudder* as in the EXIT example (which is from stock) in my first post, but I have been replacing any multiline macro as I get to it (I work as a programmer during the day, and so it is a low priority (as I add a feature, if I would need a macro, I go and replace it), since at the moment I would rather relax by adding a feature I would like to see , breakable exits at the moment, than cleaning up others code (*ponder* relaxing from coding, by going home and coding - MUDs do make you insane)

Also, while I do use _ _LINE_ _ and _ _FILE_ _ at work, it is only ever inside preprocessor stuff, since I try to make my error messages less technical (NO "General Protection Fault" crud) and I do not feel that the end user of a release version needs to know that the "error occured in Line 25, of file "\\BOB\c drive\contour\dev\surf.cpp", rather I tell them "An error has occurred in the "LycaImprt.dll" please inform....", and I guess I carry some of that over to MUD stuff too.

<std keep me from trouble notice>
NOTE: the examples above are purely that, examples (except where indicated), they are not related to any real copyrighted projects or products, and any similarity is unintentional