James Dennett wrote:
> Sean Kelly wrote:
>> Guenther Brunthaler wrote:
> 
> [snip]
> 
>>> Or let's put it the other way: D might be a valid competitor to JAVA,
>>> but it still has not got what it takes to replace C or C++ as system
>>> programming languages. It just takes more to challenge C++ than D can
>>> provide at the moment.
>> Since C++ will be adding garbage collection in the next iteration of its
>> standard, I don't see its presence in D as a particularly strong
>> argument for why D cannot compete with C++.
> 
> There's one fundamental difference: C++ language features
> and standard library are GC-neutral, i.e., will work with
> or without GC.  GC is more inherent to D (which means that
> D can benefit from certain simplifications, but also that
> you can't use so much of D if you're in a situation where
> GC isn't an acceptable option).

True enough.  But for the record, the only D feature that absolutely relies on garbage collection is associative arrays.  Normal arrays can be used without GC so long as concatenation operations are excluded, and the remaining features are all fine.  The greatest difference between D and C++ for memory management is the lack of object value semantics in D, since smart pointers have become such a popular tool in C++.  It's probably more appropriate to compare D to C here.


Sean

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

James Dennett wrote:
> There's one fundamental difference: C++ language features
> and standard library are GC-neutral, i.e., will work with
> or without GC.  GC is more inherent to D (which means that
> D can benefit from certain simplifications, but also that
> you can't use so much of D if you're in a situation where
> GC isn't an acceptable option).

I don't agree. While the library relies on gc, very little of the D core language itself relies on it - only associative arrays, and array resizing and concatenation does.

The latter array operations can also be done in D without using the gc, it's just more convenient to use the gc.

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.

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.