Oh PLEASE! Remove crappy forum "features"

[steveklabnik]

If anyone would be willing to give me some pointers on getting GDC to work successfully so I can program my OS in D, I'd really appreciate that.

Looks like you were the first one that tried something like that.

JJ

Nope, we actually have one...it was a *****. GDC isn't the way to go, though... ldc is.

http://www.dsource.org/projects/ldc

The ldc developers have said that making our os compile is a priority of their project, so I'm sure it'll be suitable for yours.

This is what D tried to do. It actually declares itself as a systems programming language, but kind of falls short. IMHO, anything with a GC is going to be unreliable for systems programming, at least in the kernel.

GC is easily turned off, and you can still use C malloc(). In the kernel you're not really using a run time anyway, so...

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...

Did we read the same link?

Lightweight inline functions:
The C Preprocessor Way

#define X(i) ((i) = (i) / 3)

The D Way

int X(ref int i) { return i = i / 3; }

The compiler optimizer will inline it; no efficiency is lost.

Or do you mean __LINE__ and __FILE__?

[earlz]

I meant __LINE__ and friends

[steveklabnik]

Yes.

http://www.digitalmars.com/d/2.0/lex.html#specialtokens

EDIT: Better link.

[earlz]

What about compilation times for identical code?
I know there is a considerable delay for C++ compared to C(with gcc/g++)
what about code optimizations and density?

I know with g++, features like exceptions took a very large chunk of time in a loop with many function calls. (according to profile information)

[JJeronimo]

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

[JJeronimo]

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.

That said, I can agree that some languages in fact need mechanisms to define new syntactic constructs. But please, do NOT use a preprocessor for this kind of stuff, instead delegate the responsibility of parsing and applying the syntax definitions to the compiler proper. Only the compiler is able to enforce syntax checking and avoid the unsafeness that is inherent to string pasting.

I can see a mostly complete way to do this for a C-like language. Consider the following syntax (I think it's obvious):

Code: Select all

syntax ("do", instr i1, "while", expr e1) means
{
 i1; while (e1) i1;
}

This could be a definition of the do (...) while loop in therms of the basic while loop.
If the syntax-definition mechanism is powerful enough to define some of the basic language constructs, then it is likely to be future-proof.

A mechanism like this could be used to define, in a safe way, a syntax for SEH infrastructures, or a syntax for coroutines.
Presently, the preprocessor only allows to do this with a bunch of dirty hacks, and the resulting syntax will most likely look strange. Again, the fact the it is even possible to do something like this with string pasting is only the product of a bunch of happy coincidences.

JJ