interest in a D compiler ?

[Letharion]

Obsolete? Wasn't 1.0 just released? I don't know very much about D, but it looks very up to date to me.

I guess they just managed to updated it before you looked

Great

[Mandr4ke]

any support in kdevelop for D yet?

I was also wondering, but i don't know if you can write D modules to read exported functions from c++ program.

[mhelvens]

A few questions (please forgive my ignorance):

How's the gdc ebuild coming? Who's creating it?

Who's "in charge" of what's put into portage, anyway?

And in absence of a gdc ebuild: How/where should I install gdc? Can I make sure it's not in the way of portage? Can I make sure that when the gdc e-build is created, I can make portage aware of my gdc installation, or at least easily reinstall it using portage?

Thanks!

By the way: I see that there's at least a syntax highlighter available for D in kwrite. Great!

[sonicbhoc]

I'd like to help out... what can I do?

[Sir Alaran]

GDC 0.23 is out. 64-bit support was added. This seems like a good time to add it to portage.

[Sir Alaran]

http://bugs.gentoo.org/show_bug.cgi?id=159196

It's now possible to build GCC with D support. Add the line

Code: Select all

D_VER="0.23"

to your gcc ebuild (in my case 4.1.1-r3) and run

Code: Select all

ebuild /usr/portage/sys-devel/gcc-4.1.1-r3.ebuild digest

then

Code: Select all

USE="d" emerge gcc

[steveL]

I noticed that there was an issue with the latest version of gcc. Any idea when that'll be sorted?

[Sir Alaran]

I noticed that there was an issue with the latest version of gcc. Any idea when that'll be sorted?

I currently have GCC-4.1.2 installed with GDC 0.23 and haven't noticed any issues. The problem may have come from using GDC 0.22.

EDIT:

should be in gcc-4.1.2 and gcc-3.4.6 now, cheers

Yay. GDC's in portage.

[steveL]

Nice one, I'll have a go at installing later in the week. Thanks for bringing D to gentoo :)

[Bowyakka]

Any tips on getting Tango working ?

[aengus]

Right now I'm playing with gdc and I've noticed that D standard library, phobos is always linked statically. Is there any reason for it?

[Vlad.Sharp]

Right now I'm playing with gdc and I've noticed that D standard library, phobos is always linked statically. Is there any reason for it?

Tango is linked statically as well - your best bet is to post something to the digitalmars mailing lists.

There is a new "D" overlay - just

Code: Select all

layman -a d

and you'll be done. It's great to see that you can use both Tango ( the "other" standard library) [ http://dsource.org/projects/tango ] and phobos both with dmd and gdc.

[Guenther Brunthaler]

I find the D language from http://www.digitalmars.com/d/ very interesting, although I haven't used it much yet.

When I evaluated D some time ago, I too found it very interesting.

I found its "Resource Acquisition Is Initialization" (RAII) paradigm especially appealing.

It really looked like a good candidate for replacing C++ at that time.

After toying around a couple of days with D, however, I found at least the following reasons why I chose *not* to use D, and rather stick with C++:

* While the closed source Digital Mars compiler really created small and nice executables, the GCC-backend created executables multiple times that size

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

* Even though D propagates RAII, it actually fails supporting it itself in a way that makes sense.

The last problem is due to D's destructors.

In order to implement RAII for real-world objects like a "file object" which automatically closes the file it controls as soon as the lifetime of the object ends, one needs synchronous destructors.

That is, destructors are required which are not invoked at some time, such as when the garbage collector considers it a good idea, but at a known instant, such as when the object variable representing the file goes out of scope.

Some programming languages try to emulate that feature using "finally", but this is not the way RAII is going to work: In RAII-capable languages, the destructor cleans up an object automatically at the right time, not some explicit code in a finally-clause.

JAVA does not have RAII in that sense, because its destructors are not under control of the programmer. (IMHO, this is one of JAVA's greatest disadvantages when compared to C++.)

On the other hand, not all objects need RAII - this is only necessary for objects which manage resources.

For other object it's just fine if the GC controls their actual lifetimes.

So, for an RAII-capable language it is mandatory the language provides synchronous destructors, while it is OK if the language also provides a GC (featuring asynchronous destruction) for those simple objects which don't require RAII.

JAVA is a language not capable of RAII for those reasons.

Ruby has partial support for RAII but only if you nest code blocks in an unintuitive way.

Perl, Python and C++ are fully capable of RAII, using their "DESTROY", "__del__" and "~name" destructors, respectively.

And what about D?

In theory, D has both: JAVA-like GC-controlled destructors for normal objects, and "auto"-destructors for those cases where RAII is required.

But D's "auto" keyword has a severe bug by design: It is not attached to the class definition, but to object variable definitions!

For instance, given the code

Code: Select all

class FILE { ... };
auto FILE fok;
FILE fbroken;

then "fok" is an a usable FILE object which has the RAII sematics a FILE object requires, but "fbroken" is a non-functional FILE object as it will not work the way a FILE object is supposed to work (closing the controlled file handle as soon as the object variable goes out of scope).

And "fbroken" is only broken because the "auto" keyword was missing!

Clearly, as the "auto" keyword in D drastically changes the semantic of an object, it should either be applied to all objects of some given class, or to none.

The "auto" keyword therefore should be part of the class declaration, not of the object variable declaration.

Because otherwise, omitting the "auto" keyword - such as by mistake - changes the semantics of an object, but the compiler won't detect it.

Also, it forces the developer to decide whether RAII semantics are required for the objects of a given class or not.

It is not just possible to later reconsider the initial decision and add RAII semantics to some class, because in that case it would be necessary to add the "auto" keyword to each any every variable declaration in every program that uses this class.

This all is a maintenance nightmare, and a bug by design.

It essentially renders D unusable, at least with regard to RAII.

On the other hand, perhaps they have changed this behaviour since the last time I have looked at D.

But if they did not, that severe design bug is a very good reason NOT to use D.

[Vlad.Sharp]

Ok, for the moment I have an overlay for D which supports dmd, gdc (0.24_pre) and tango - for instructions see http://gentoo.arsfides.com/wiki

I hope to get more D projects from dsource working

[didl]

* Even though D propagates RAII, it actually fails supporting it itself in a way that makes sense.

The last problem is due to D's destructors.

In order to implement RAII for real-world objects like a "file object" which automatically closes the file it controls as soon as the lifetime of the object ends, one needs synchronous destructors.

That is, destructors are required which are not invoked at some time, such as when the garbage collector considers it a good idea, but at a known instant, such as when the object variable representing the file goes out of scope.

D has scope classes to do RAII.

[Guenther Brunthaler]

D has scope classes to do RAII.

This must be something new then!

May I ask you whether you could provide some short example, how to write something like

Code: Select all

class file {
   file() {
     puts("Opening file");
   }
   ~file() {
    puts("Closing file");
   }
};

public main() {
   puts("Before opening the file.")
   {
      auto file f;
   }
   puts("After closing the file.")
}

with "scope classes", so that the dangerous "auto"-construct in the variable declaration can be avoided? (Sorry if the above code might not actually be valid D, but it has been a long time since I had evaluated D, and I do not currently have a compiler installed for verifying the code. But I hope you still get the idea what it should do.)

I would really very appreciate that, because the D documentation is long and I would prefer not to have to sift it through again just for a single new feature.

If scope classes actually solve the "auto" problem, however, I will give D another try for sure!

[didl]

I guess you'd do something like

Code: Select all

import std.stdio;

scope class file
{
  this()
  {
     writefln("Opening file");
  }
  ~this()
  {
    puts("Closing file");
  }
}

int main()
{
  writefln("Before opening the file.");
  {
    scope file f = new file;
    //int[] test;    
    //test[2] = 5;     // destructor for file is called even
                       // if scope is exited via a thrown exception
  }
  writefln("After closing the file.");

  return 0;
}

With scope classes the destructor is called even if the scope is
exited via a thrown exception (see the commented code).

[Guenther Brunthaler]

I guess you'd do something like [...] (see the commented code).

Yes! Exactly like that!

The last time I looked at D (two years or so ago), the "auto" specifier in an object variable declaration was the only possibility to get what now "scope" seems to accomplish.

So, I really have to thank you very much - this single improvement turns D into a language of interest for me once again!

I'll start studying the updated language specs as soon as I have some time left to do so - and perhaps, "thanks" to the update of the libexpat.so.0 which keeps my system busy compiling hundreds of updates as a consequence of revdep-rebuild, it'll even be as soon as today!

[Guenther Brunthaler]

Code: Select all

...
  {
    scope file f = new file;
    ...

When checking http://www.digitalmars.com/d/class.html for that new "scope"-class feature in more detail, I unfortunately had to learn that only half of my critique on D's synchronous destructors has been rendered obsolete by the new D 2.0 design.

What they have actually done was renaming "auto" into "scope", and forcing to add the "scope" declarator to both the class declaration as well as to object variable definitions.

While this is clearly an improvement, because the compiler can now detect missing "scope" declarators in object variable definitions and give an error message, it still does not solve the problem that it is necessary to write "scope" at the object variable definitions.

This can and will become a problem in evolving projects.

Of course, in a perfect world each application will be completely designed before even the first line of code is written.

In such an optimal scenario, all the classes will be properly defined before the actual coding starts, and for each class it will be thus known in advance whether it requires a "scope" declarator or not.

In this perfect world, it will always be clear from the beginning that all the object variables ever defined for objects of such classes must also include the "scope" declarator.

But in the harsh reality of real life, things rarely if ever work out as smoothly as in our perfect-world scenario.

Real programs evolve over time.

It is quite common to add functionality to classes later which no-one has thought of when they have been designed in the first place.

This is especially true in open source projects, where multiple external developers add code to an existing project, adding things the original author might have never dreamt of.

Now imagine there is a D class in such a project which initially did not manage any resources but memory.

Such classes usually don't have any special destructors, because they leave it to D's garbage collector to eventually deallocate the memory. Also, as such classes do not control any particular operating system resources, there is no need to declare them as "scope". And of course, no object variable throughout the project will have been declared "scope" in order to match the class declaration.

Let's assume 50 developer are working on such a project.

What happens if any of them decides to add a feature to our class which requires controlling some operating system resource other than memory - say the handle of a class-internal log file?

Note that the developer only added functionality to that class by adding some sort of logging framework interface to it; this is new functionality which does not interfere with any existing functionality if the class.

Adding such functionality is in fact quite common, and has never been a problem in C++: In this case, the header file will be updated and all dependent source files will have to be recompiled - a process automatically taken care of by the "make" utility (assuming a correctly written Makefile).

But the existing C++ source files do not have to be modified in any way because of this change.

Not so in D.

As adding something as a logfile feature to a class in a well-co-ordinated way usually requires some cleanup to be done in the destructor (such as closing the logfile) and this cleanup should be done in a predictable manner, it is necessary to convert the non-"scope" class into a "scope"-class.

But in contrary to C++, it is not enough to add "scope" to the class declaration in D.

No, in addition to that, all the source files of all the 50 programmers in the project have to be scanned for object variables defined for this class, and "scope" has to be added to any such instances found.

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.

The solution to that problem should also be obvious: The requirement to repeat the "scope" keyword from object variable definitions has to be dropped.

It seems to be unnessesary anyway, because the compiler will find the "scope" when it looks at the class declaration; it is pure nonsense to repeat that declarator at each object variable definition for that class over and over again. (That is, nonsense from the view of an application developer programming in D. Perhaps there is good reason to do so from a language designer's point of view. But that excuse won't help avoid the maintenance problem.)

Summing up: By changing "auto" into "scope", D 2.0 has been updated from "nearly unusable" to "just unmaintainable", at least for large-scale projects which are have a design based on RAII.

For smaller tasks D might be OK - but then, why not using a simpler language like Python, Perl or JAVA instead? (And Python, albeit "just a scripting language", is even more powerful than D regarding RAII, because it already has synchronous destructors - no need for any "scope"-like declarations there. Same for Perl.)

Another problem of D is inherent from its design decision to use garbage collection: As http://www.digitalmars.com/d/garbage.html states,

All threads other than the garbage collector thread must be halted while the collection is in progress.

In other words, even the most high-sophisticated multi-threaded web-server written in D must be expected to take a nap at any time - and all threads running will have to take a nap, too. Great - that was exactly what multi-threading was made for. And no-one can say how long this nap will actually take, because

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.

Of course, JAVA has the same problems. But it is D and not JAVA claiming C++'s crown.

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.

On the other hand, D is still an evolving language, and so there is still a chance left for hope that those shortcomings will eventually be eliminated.

[didl]

Hi Guenther,

Thank you very much for your post and insight. I'd really like to encourage you
to summarize your points as concisely as possible and post them to the D forum.
You likely will get a much more sophisticated answer to your critique over there and your opinion
may actually influence the design process of D. In order to make D a better C++, input from the
community is paramount.

[EDIT - some random thoughts]
Making a scope class out of a non-scope class will indeed "break" the code of users of that class.
On the other hand, this breakage is easily fixed since the compiler will exactly tell you what to fix.
Furthermore, the "scope" keyword clearly indicates what the class is intended to do and one may
argue that it is the responsibility of the writer of the class to design it properly in the first place.
That is, one could argue that if there are a lot of classes that need to become scope at some
point during the development process there may have been a flaw during the initial design process
of the class(es). As a user of a scope class I clearly know what its intention is (at least from an RAII
point of view), something that is not the case in C++. If the designer of a class changes it from
non-scope to scope I as a user of that class at least know that something fundamental has changed
in the way the class is supposed to be used; maybe that's a good thing at least with respect to
the quality of the final product.

[meyerm]

I'd really like to encourage you
to summarize your points as concisely as possible and post them to the D forum.

If you do that, could you please give us feedback in this thread when a discussion is taking place?

Thank you for your very well written critics on D
M

[Guenther Brunthaler]

Hi didl,

I'd really like to encourage you
to summarize your points as concisely as possible and post them to the D forum.

Good idea - done!

I have posted it there as:

http://www.digitalmars.com/webnews/news ... e_id=57001

[Guenther Brunthaler]

If you do that, could you please give us feedback in this thread when a discussion is taking place?

OK, if anything interesting comes up, I'll post it here.

[anyc]

Where is the right place to ask for a patch that builds a PIC version of phobos?

On x86_64 it seems impossible to use shared libraries that are linked against
non-PIC libraries. :/