• ### Announcements

#### Archived

This topic is now archived and is closed to further replies.

# D Language?

## Recommended Posts

Has anyone seen this new (about a year old) D Language? I was wondering if anyone had any first impressions on it. At first glance I think it has some interesting features. For example, strong typecasting of typedefs. If you define a type SPEED to be a float, in D you can''t use a float in the place a SPEED variable. There are some things I think look appealing. What do you guys thing?

##### Share on other sites
I am also interested in that thing, but now im learning c++ again so its better to stay away from that.

D looks somewhat more python like :D there is even garbage collection included. But i wont read more of that site now

##### Share on other sites
I''ve seen this before, I didn''t look into it much, though. I''ll take a look at it! Thanks for the link. Garbage Collection alone is great!

daveandrews.org, soon to be home to a GAPI Sprite Engine.

##### Share on other sites
i moved completely from c++ to d and there is no reason for me to ever wine about it. it was the best move i''ve ever made. i was never faster, more productive, more efficient, and bether in programming in general than now.

D is great.

of course, thats just my opinion..

but other things that are great about it: size: it fits completely onto a floppy, the whole minimum toolset is about 700kb big
compiler speed: the compiler is VERY fast, this mainly due to the slim, elegant language design
i can use D as scriptinglanguage and programminglanguage at the same time in the same app, hehe.. due to that size and speed features of the compiler..

i really love it..

If that''s not the help you''re after then you''re going to have to explain the problem better than what you have. - joanusdmentia

davepermen.net

##### Share on other sites
I might give it a try. What IDE do you use? Can I get it to work with VS.NET?

##### Share on other sites
quote:
Original post by Rayno
Has anyone seen this new (about a year old) D Language? I was wondering if anyone had any first impressions on it.
The page says December 1999.

Actually, I find that plays in its favor... A language almost four years old may be worth checking out.

I''ve glanced over it a few times, but my conclusion is that until D becomes mainstream, I''ll continue to use C++ for performance-critical code, and some other high-level language for the rest.

Cédric

##### Share on other sites
quote:
Original post by Cedric
quote:
Original post by Rayno
Has anyone seen this new (about a year old) D Language? I was wondering if anyone had any first impressions on it.
The page says December 1999.

Actually, I find that plays in its favor... A language almost four years old may be worth checking out.

I've glanced over it a few times, but my conclusion is that until D becomes mainstream, I'll continue to use C++ for performance-critical code, and some other high-level language for the rest.

Cédric

i don't see the need or fascination for it to be "mainstream". D is C and C++ compatible and conforms to the current standards of both. so unless you proved that code you run on ur C++ compiler of your choice runs that much faster than a D compiler, i don't see the validity of your statement of your statement, well besides the subjective point.

the only issue that i see with it is that it doesn't do multiple inhertance. from what i hear. that's a good thing :D

edit: the later posters are correct. my apologizes. the current standards are not handled completely, as i had said prior. excuse the misreading.

[edited by - Alpha_ProgDes on October 13, 2003 10:33:04 PM]

[edited by - Alpha_ProgDes on October 13, 2003 11:32:57 PM]

##### Share on other sites
quote:

D is C and C++ compatible and conforms to the current standards of both.

quote:

the only issue that i see with it is that it doesn''t do multiple inhertance.

These two statements appear to contradict each other ...

##### Share on other sites
anyone know what they mean by "Nested Functions" or "Function Literals?" These are the only things that sound interesting to me.

##### Share on other sites
Wow, now THIS is nice.

From the Converting C++ to D page:

quote:

Comparing structs
The C++ Way
While C++ defines struct assignment in a simple, convenient manner:

struct A x, y;
...
x = y;

it does not for struct comparisons. Hence, to compare two struct instances for equality:

#include <string.h>

struct A x, y;

inline bool operator==(const A& x, const A& y)
{
return (memcmp(&x, &y, sizeof(struct A)) == 0);
}
...
if (x == y)
...

Note that the operator overload must be done for every struct needing to be compared, and the implementation of that overloaded operator is free of any language help with type checking. The C++ way has an additional problem in that just inspecting the (x == y) does not give a clue what is actually happening, you have to go and find the particular overloaded operator==() that applies to verify what it really does.

There''s a nasty bug lurking in the memcmp() implementation of operator==(). The layout of a struct, due to alignment, can have ''holes'' in it. C++ does not guarantee those holes are assigned any values, and so two different struct instances can have the same value for each member, but compare different because the holes contain different garbage.

To address this, the operator==() can be implemented to do a memberwise compare. Unfortunately, this is unreliable because (1) if a member is added to the struct definition one may forget to add it to operator==(), and (2) floating point nan values compare unequal even if their bit patterns match.

There just is no robust solution in C++.
The D Way
D does it the obvious, straightforward way:

A x, y;
...
if (x == y)
...

Beautiful!

daveandrews.org, soon to be home to a GAPI Sprite Engine.

##### Share on other sites
I checked it out about a year ago, but a few things put me off. Surprisingly, most of them are what it sees as it''s highlights.

Garbage collection.
The spec states (IIRC) that the D language is not good for real-time applications because garbage collection can in some cases take quite some time, and cannot be paused. (This may be slightly incorrect, or old info, though. Feel free to correct). This seems to make it inappropriate for fast-paced games as it may occasionally freeze for a short period.
The main problem I see with it is that it looks like it is rather hard to avoid using it.

Arrays
All arrays have a size variable at the start.
With multiple small arrays (eg a binary tree with node->child[2]) this can waste much space. And AFAIK it''s not very useful.

There are other things. Mainly, I think it''s too high-level for me. It seems situated halfway between Java and C++.

There are definately many good points about it. I especially like modules replacing header files and "real typedefs", but I don''t think I can change to it unless I can do all the memory management easily myself.

##### Share on other sites
quote:
Original post by Martee
quote:

D is C and C++ compatible and conforms to the current standards of both.

quote:

the only issue that i see with it is that it doesn't do multiple inhertance.

These two statements appear to contradict each other ...

Yeah, it's definetly not C and C++ compatible, just similar. Thinks like pre-processors are non-existant, so writing code for multiple OS's in a single source file is not going to happen. Garbage collection sucks, because it makes people lazy, and even if there isn't a memory leak, leaving memory loaded that is no longer needed is still wasting memory that could be used by other parts of the program.

--- Edit ---
By the way, this is what I noticed last year or so when I looked at it a bit. They take the best parts OUT of C and C++, add a few features that make your programs much slower and can't be turned off, and call it a better language. I agree, it's more of a mix between java and C/C++ (without making mlutiplatform binary code of course).

[edited by - Ready4Dis on October 13, 2003 11:22:36 PM]

##### Share on other sites
To Ronin Magus:

I believe the reason C++ does not provide default == behaviour for structs is that many structures may be conceptually equal even if their variable data differs, and it doesn''t want you to mistakenly use it.

Take for instance a very simple string class.

class CSimpleString {
char *chars;
...
};

two CSimpleStrings could both contain "Bob", but have their character data in different regions of memory. The default == behaviour would make them not equal.

So C++ is taking the safe approach, wheras D is taking the reduced complexity approach. Seems to me that both have their justifications.

-------------

Here''s an interesting idea: A modular customizable compiler.

Basically you somehow define a compilation environment, then compile. Garbage Collection could be one module. Strong typedefs another, and "array size" values a third. Then nobody could really complain that any module-feature makes the language worse.

##### Share on other sites
I like D a lot; with any luck it'll manage to get some mindshare within the next few years and become a credible alternative. The main thing holding it back now is its obscurity. There are few tools that support it, and few libraries coded for it. (the main reason I like C++ so much is because the available tools are so mature and robust. VS.NET rules. :D)

You can see a (sucky) little demo of an engine I started coding with it here. (the model and texture are borrowed from Egoboo, which is pretty awesome in its own right, but that's neither here nor there)

(FYI, it's OpenGL/SDL, using libpng to load textures)

And now for the responses:
quote:
anyone know what they mean by "Nested Functions" or "Function Literals?" These are the only things that sound interesting to me.

Nested functions are functions declared within other functions. They get a pointer to the stack frame of the outer function, and therefore have access to locals declared in the outer function. This isn't a true closure, but it's close enough for all sorts of interesting things.

Function literals are the same idea as Java's anonymous classes, except they're just functions. It's handy in places where you would use a C++ functor:
sort(someList, delegate(Object a, Object b)     { return a.lessThan(b); });

I also like using them for callbacks for GUI widgets.
quote:
Arrays
All arrays have a size variable at the start.
With multiple small arrays (eg a binary tree with node->child[2]) this can waste much space. And AFAIK it's not very useful.

D's arrays are implemented just like C if you specify a size in the type. ie int[8] x;

Dynamic arrays are declared like Java: int[] x;
quote:
These two statements appear to contradict each other ...

Only because one is wrong. D makes no attempt at binary compatibility with C++ classes, and no attempt at source compatibility with either. D offers no multiple inheritance; it borrows Java's interface concept. The reasoning is that doing so simplifies the compiler. (one of the overt goals of D is to make the compiler easy to implement, so we don't have to wait 10+ years for a compiler that works right)
quote:
Yeah, it's definetly not C and C++ compatible, just similar. Thinks like pre-processors are non-existant, so writing code for multiple OS's in a single source file is not going to happen. Garbage collection sucks, because it makes people lazy

I think he means that D links with C easily. And it does.

Versioning and debug blocks are an explicit part of the language that work symbolically, instead of textually. They also look a lot nicer.

version (Windows) {   // windows things ...}else version (Unix) {   // UNIX things}else {   // any other version}

As for GC making people lazy, that's kind of the whole point of any language higher level than assembly. Forget silly details, move on to more important things.

Granted, there are times when GC just gets in the way, and the language is designed with that in mind. D's garbage collector is pretty unintrusive; you can disable it for speed critical blocks. (it still tracks objects during this time, but won't collect) You can also override class allocators and deallocators if you want to stay clear of it, or need to do some speed hacking.

I'm hip because I say "M\$".

[edited by - the speed bump on October 13, 2003 12:19:04 AM]

##### Share on other sites
quote:
Original post by Cedric
The page says December 1999.

My mistake. The first entry on the changelog was Sep 28, 2002.

quote:
Garbage collection sucks, because it makes people lazy [...]

This doesn''t seem like good reasoning. You could just as easily say that anything not written by hand in ones and zeros is lazy. Care to elaborate?

##### Share on other sites
quote:
Garbage collection sucks, because it makes people lazy

Drivel.

##### Share on other sites
gc doesn''t make you lazy, but eighter lets you concentrate on the important stuff..

i could stip out about 30% of my c++ engine at the moment i ported it to d, just because it was complex exception handling, assert routines, memory management, data managers, and all sort of things, wich got unneeded in D. in c++ there is no real save and fast way to work with data, and this sucks and results in tons of funny workarounds.
the gc solves this all. and it does not hurt in realtime apps at all. as long as you don''t allocate/deallocate any stuff, it doesn''t run. else, you can explicitely disable it during the time critical code if you need to. no problem there.

D as a language is much more clean than c++, much more simple, and logical. it has less of those obscure "tricks" we all love and hate in c++. its straightforward and simple. this is great to code. its not that i''m perfectly happy with everything (yet)

hm.. has been hours since i wrote that.. no clue where i was, had a lot of administrative things to do in between.. i''ll just post:D

If that''s not the help you''re after then you''re going to have to explain the problem better than what you have. - joanusdmentia

davepermen.net

##### Share on other sites
quote:
Original post by davepermen
you can explicitely disable it (gc) during the time critical code if you need to. no problem there.
But the problem with D''s applicability to games is that in games you are in constant critical code. You can play the game for 30 minutes, and never want it to stall for a second to do GC. If D''s GC didn''t happen in such bursts, but spread over the whole time (more or less), I wouldn''t complain (no experience on the slowness bursts though, just what I read from Krylloan)

##### Share on other sites
quote:
The reasoning is that doing so simplifies the compiler. (one of the overt goals of D is to make the compiler easy to implement

One of the overt goals of C++ was to make a general purpose language that could solve a large range of problems.

Rather Java-like, the inventor of D has apparently decided which features of C++ are useful and which are not and designed his language accordingly. I''m glad it''s easier for compiler writers, but I prefer a language that makes my life as a *programmer* easier. Being forced to use certain features because there''s no choice (GC) and not have the choice to use others (MI, preprocessor, etc) is not my idea of easy.

--
Dave Mikesell
d.mikesell@computer.org
http://davemikesell.com

##### Share on other sites
quote:
Original post by dmikesell
but I prefer a language that makes my life as a *programmer* easier.
I sure hope you don''t imply C++ is this language that makes "life as a programmer easier", even though your post had strong indications hinting to this direction. No.. You can''t possibly mean it. I mean, it''s absurd.

##### Share on other sites
easier for the compiler means more logical and like that more simple for the programmer, too..

the result is c++ without all the complicated exceptions of the language.. it "bugfixes" them.

and the compiler friendly results in a HUGE performance boost for compiling.. instead of having to recompile the linux kernel over night, you could do it in minutes:D

oh, and in a game, you normally don''t need much "time critial" situations ONLY. a lot of games are "sectorbased", and during switching them you could have a framedrop to say 30fps once..

think of unreal and the way its played. during those loading times gc is essencial, and there you can enable it, after loading make a full collect with defrag, and then, while in the sector, just make incremental small fast collections. they don''t really hurt, and should be enough to collect your small random allocated data.

but as always, you should not allocate much objects during runtime, same as you should not use a lot of new in the mainloop as it slows down, too..

the gc is a nonissue.. you have to learn to think with it, of course. but it makes life so much easier, and if done right, it doesn''t hurt any more than normal new/delete ever did.

most games use "garbage collectors" for their resources anyways, even while handimplemented, they would mean a framedrop while running..

it all depends on the app, of course..

i''ve yet to see a game that really needs to be in constant critical code..

If that''s not the help you''re after then you''re going to have to explain the problem better than what you have. - joanusdmentia

davepermen.net

##### Share on other sites
quote:
Original post by dmikesell
Being forced to use certain features because there''s no choice (GC) and not have the choice to use others (MI, preprocessor, etc) is not my idea of easy.

Garbage Collection is not a language feature (in terms of an expressive construct), although it is a feature-enabling concept which can help widen the expressive range of the language. The point of GC is not necessarily to simply clean-up after the programmer, but to automate various idioms which would otherwise require amounts of irrelevant manual tedium. C++-centric programmers tend to miss this important detail, since it is rather difficult to imagine language features that are not available to them. This leaves object clean-up as the only perceived use of a GC system, leading to the belief that GC is only good for programmers who forget to clean-up after themselves.

As for leaving out language features, I''m inclined to agree. Or at least, I agree that it is bad to reduce the expressive freedom available within a language. My perception is that MI and the preprocessor are both conceptually broken'' in C++. However, few people agree (or even understand the argument) that they are conceptually broken, so the actual rationale I often see is that they are open to misuse'', which I consider a feeble reason for excluding something.

##### Share on other sites
quote:
the result is c++ without all the complicated exceptions of the language.. it "bugfixes" them.

That''s the difference between us - I don''t see C++ features as bugs.

quote:

the gc is a nonissue.. you have to learn to think with it, of course. but it makes life so much easier, and if done right, it doesn''t hurt any more than normal new/delete ever did.

Allocate in constructor, de-allocate in destructor. Use std::auto_ptr or boost::shared_ptr to avoid leaks in the face of thrown exceptions. And there are 3rd party GC''s available for C++ if you really want one, but if you use modern C++ idioms they aren''t really necessary.

--
Dave Mikesell
d.mikesell@computer.org
http://davemikesell.com

##### Share on other sites
quote:
Garbage Collection is not a language feature (in terms of an expressive construct), although it is a feature-enabling concept which can help widen the expressive range of the language. The point of GC is not necessarily to simply clean-up after the programmer, but to automate various idioms which would otherwise require amounts of irrelevant manual tedium.

A couple questions about D's GC. 1) Does it close file handles, sockets, release semaphores and other resources? Or just memory? 2) How does one disable it?

quote:

C++-centric programmers tend to miss this important detail, since it is rather difficult to imagine language features that are not available to them. This leaves object clean-up as the only perceived use of a GC system, leading to the belief that GC is only good for programmers who forget to clean-up after themselves.

What else does it do (besides "automate various idioms")? And what are those idioms?

quote:
My perception is that MI and the preprocessor are both conceptually broken' in C++.

I'm more inclined to blame programmers and not their tools for bad programs. How many questions do you see on this forum that could be answered in the most rudimentary C++ text?

--
Dave Mikesell
d.mikesell@computer.org
http://davemikesell.com

[edited by - dmikesell on October 14, 2003 8:18:57 AM]

[edited by - dmikesell on October 14, 2003 8:19:33 AM]

##### Share on other sites
quote:
Original post by dmikesell
A couple questions about D''s GC. 1) Does it close file handles, sockets, release semaphores and other resources? Or just memory? 2) How does one disable it?

Sorry, I didn''t make it clear where I was coming from. My comments about GC were more general than just the D POV. I was responding directly to your implication that being forced to use GC is a restriction on expressive freedom and indirectly to Ready4Dis''s comment about GC creating lazy programmers. I''ve not programmed anything non-trivial in D, so someone else will have to answer your questions.
quote:

What else does it do (besides "automate various idioms")?

I perceive the idiom-enabling aspect to be the more important. Automated clean-up is something else you get, but I find the sole value of that to be low.
quote:

And what are those idioms?

Lexical closure and first-class functions.
quote:

I''m more inclined to blame programmers and not their tools for bad programs.

I was explicitly talking about the broken'' mechanisms, irrespective of the people who use them. Its my opinion that MI as realised in C++ is conceptually broken. That''s not to say it doesn''t have its uses.
quote:

How many questions do you see on this forum that could be answered in the most rudimentary C++ text?

Lots, but that has nothing to do with my previous claim. I''m not suggesting the mechanisms are broken because people misuse them, but because they do not fully realise the concepts which they are supposed to, and that some problems in their usage result from that. In particular, the fact that the class construct in C++ conflates the two concerns of type definition and of symbol namespace is a problem. Also, member functions are only ever allowed to act virtually wrt the first (implicit) parameter, which I also consider a problem. Those two malformations together are (can be) a serious impediment to expressive freedom when building class-hierarchies.

The really unfortunate thing is that languages like Java recognise there is a problem with the implementation of certain C++ concepts, but avoid fixing them by simply not incorporating the concepts. This is a result of marketing-driven language design. It was more important to have something designed and implemented as a better C++'' (which, make no mistake, is no small feat of engineering in itself), in order to gain market-share, than it was to spend time actually resolving the perceived problems in C++. This is known as Money-Oriented Programming''.

• ## Partner Spotlight

• ### Forum Statistics

• Total Topics
627654
• Total Posts
2978444

• 10
• 12
• 22
• 13
• 33