earlz wrote:What about using the preprocessor to increase speed of the program, and ease on the developer?
I discovered the C preprocessor was capable of this nifty little thing earlier yesterday.
Code: Select all
#define PANIC(x)\
epbp_panic(x,__FILE__,__FUNCTION__,__LINE__)
With this, I get where the panic occured in my code, and the code(x) for the panic. Before I knew of this, I had to either type that huge long line, or just use codes, which didn't tell me exact information.
Oh yeah! And what if you want to add a string argument explaining the reason for the panic? In no time at all, you'll be dealing with the almost useless C99 variadic macros and such. (because I believe you want format strings). For details read:
http://groups.google.pt/group/comp.lang ... 27f5202340
the preprocessor is very handy in the hands of those that know how to use it. But, it can be easily abused too.
The C preprocessor is plain dumb. It drives you into hackish stuff very very quick. Those "that know how to use it" are those who are able to cope with the limitations of string pasting and aren't afraid to pay the price for the extra dirty hacks to work around those limitations.
The limitations of string pasting mean that the fact that you are able to "extend" the language is just the product of some happy co-incidences. As long as those happy co-incidences last, you don't have to employ dirty hacks. At the point that the co-incidences end, the dirty hacks become increasingly necessary, and the preprocessor becomes a mass destruction weapon.
Some time ago, I read something in the ReactOS wiki that summarized this quite well. It said something like string pasting is evil because it gives you a
wrong sense of flexibility.
For example, consider the usual C approach to function "inlining". This works for some functions because of a happy co-incidence, that is, those functions are composed of only one expression, so they don't rely on the
return keyword. However, if the function has to use loops, you cannot convert it into a macro, because that functions:
1 - use something that is NOT an expression
2 - and thus have to use
return
And so, because of 1, you need to use a compound statement in your macro, and compound statements cannot return values (only functions can return values).
Is there any way to do this in your precious D? I didn't see any replacement for such a macro in that C preprocessor vs. D link...
I don't know D very well, but I doubt there isn't, if anything, some predefined syntax to accomplish the same goal as your macro.
As about a way for defining yourself the syntax to do this, in fact I believe you cannot. But I already explained you why I believe macro expansion to be the wrong way to extend a language.
JJ