scope keyword - a maintenance nightmare?

[Walter Bright]

Guenther Brunthaler wrote:
> * There is is no equivalent to MODULA 2s "Definition Modules". While
> I think it is a good idea to get rid of C++'s primitive "header"
> files, there must still be some means of separating interface
> descriptions from the actual code. Otherwise, you always have to ship
> the complete source code to anyone who just wants to use some
> interface as a client. Consider writing a plugin for OpenOffice.org
> that way...

There is such a mechanism, .di files. They can be written either 
manually, or automatically generated with the -H switch.

> * Maintenance-Nightmare with "auto" (now "scope").
[...]
> 
> Just consider the "fun" those programmers might have, especially in a
> distributed development scenario, when they note their code no longer
> compiles after each couple of updates they receive from the main
> version control repository, and forces them to add dozens of "scope"
> declarations to their variable definitions, because "scope" has been
> added to the declaration of some class they are using.
> 
> I consider such a situation to be a maintenance nightmare.

You have a good point in questioning the redundancy of requiring the 
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, 
because the compiler will tell you where the changes need to be made. A 
nightmare is when the compiler doesn't say anything, but the recompiled 
code no longer works.

I can point to several such nightmares in C++ that are plugged in D - 
see the recent thread about slicing of polymorphic objects for one example.


> The time it takes for a collection to run is not bounded. While in
> practice it is very quick, this cannot be guaranteed.
> 
> Such interruptions of normal service might be tolerable in many
> situations, but not in all.
> 
> D is therefore especially not well suited for real-time applications.

I've written some real time code in the past, and have talked to people 
who write real time code professionally. You cannot use new() in C++ in 
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).

How hard real time code is written is all the memory needed is 
preallocated, and the real time code does not do memory allocation.
The D garbage collector will not arbitrarily or randomly pause your 
program, as collection cycles only run synchronously with calls to 
allocate gc memory. If there is no attempt to allocate gc memory, your 
app is guaranteed to not run a collection cycle.

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

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