scope keyword - a maintenance nightmare?

[Walter Bright]

Guenther Brunthaler wrote:
> 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.

I think there's a misunderstanding here. C++ compilers aren't required 
to support ".h" files either - .h is just a convention. The C++ standard 
says nothing at all about file extensions. There is nothing special 
about .h files, they are filled with standard C++ code.

Ditto for .di files. They are filled with standard D code. There is 
nothing whatsoever different about the syntax in them - it's standard D, 
and can be handled by any D compiler.

What was meant by the comment in the spec is that a compiler can 
implement interface files in its own proprietary format. But it still 
must read standard D files, and .di files can be written as standard D 
code, and always can be.

It's quite analogous to C++ .h files. Yes, it is allowed for a C++ 
compiler to have .h files in some special proprietary format - but all 
C++ compiler still must compile standard C++ code.


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

Sure. But also consider that, while C++ objects are designed from the 
ground up to be RAII, in D they generally are not. So it might be very 
worthwhile to be notified by the compiler where objects are declared, as 
  a review of their use might be in order when switching the design of 
it to be RAII.


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

Yes, all of which you can do with D. Note that you can also override 
operators new and delete on a per-class basis.


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

Nothing special, just don't use it.


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

These could be better documented, but they are usually fairly obvious.