bearophile wrote:
Walter Bright:
Why couldn't you do the exact same thing in D?<
Those ctips show some tricks done with the preprocessor that I don't know yet
how to do with D1, and there are some situations where in D I'd like to be able
to locally disable array bound checks (this is doable in Delphi/FreePascal),
like in the data array here:
typedef struct {
int size;
int capacity;
char data[0];
} Mystring;
(untested)
struct Mystring {
size_t size, capacity;
char* pdata() { return cast(char*) (&this + 1); }
char[] data() { return pdata()[0 .. size]; }
}
But D is more or less a superset of C, so a D programmer may be able to
implement all those things, as you say.
The main point of my original post is that some of those ctips may be added as
built-in idioms to D.
I've had a nice "blast from the past" feeling while skimming the
document, but really it's more of a proof that with ingenuity and
discipline a bear can be made to dance. I don't see how that stuff could
help D any more than a coconut and two straws could help a radar receiver.
I have been mightily disappointed (essentially my respect for the author
has crashed into the ground) when I saw that the entire optimization
example, although clearly a lot of time and effort has been put into it,
had absolutely no numbers whatsoever.
Regarding possible things to be added to D: recently I have heard that some
people is thinking about creating a small C compiler that supports some
nonstadard low-level features, to be used to compile the future Linux kernel:
http://lkml.org/lkml/2009/4/22/78
If such project goes on, then it may show other things that may be useful in D
if D wants to be fit to write kernels too.
IMHO all D needs for writing kernel-grade code is a way to code cleanly
without the GC.
Andrei
