scope keyword - a maintenance nightmare?

[Guenther Brunthaler]

Walter Bright Wrote:

> > * There is is no equivalent to MODULA 2s "Definition Modules". While
> There is such a mechanism, .di files. They can be written either 
> manually, or automatically generated with the -H switch.

Well, yes. But the D 2.0 specs say that di files are not part of the language standard and a mere optimization. That is, a feature much like precompiler header files: Quite useful, but by no means standardized.

No D compliant compiler is therefore required to support di files, nor is there any guarantee about the format of such files and that they have to be compatible between different implementations.

> scope keyword on declarations if it is on the class. But I disagree that 
> it's a maintenance nightmare. Tedious, possibly. But a nightmare, no

OK. But you got the idea.

> real time code; you cannot even use malloc()! Why? Because the execution 
> time of new() and malloc() is NOT bounded (and it cannot be bounded).

I think realtime applications have to use the services provided by a real time operating system.

If some of those services map to malloc and can guarantee bounded execution time, than that's fine.

If not, then the application must not use malloc but write its own memory management code or statically pre-allocate as you suggested - whichever seems more appropriate.

> allocate gc memory. If there is no attempt to allocate gc memory, your 
> app is guaranteed to not run a collection cycle.

That's good news.

But is this behavior documented somewhere in the official D specs? I certainly did not find such a guarantee when reading the specs the first time. But then, this has been 2 or 3 years since.

> Absolutely this (preallocating memory) is possible in D, and it's just 
> as straightforward as in C/C++.

I was not aware of this either.

> You can completely avoid using gc memory in D if your app requirements 
> so choose, using only malloc/free, or even statically allocate all 
> memory (the D version of Empire did this).

Very good! It there anything special one has to do in order do avoid running the GC? A HOWTO or something?

I'm pretty sure one cannot use all of the standard library if CG runs are going to be avoided. So it's important to know which standard functions/features can be used and which can't in realtime applications.