I heard people talking about D and I Googled it.  Apparantly it's an improved version of C++ (obviously from the name).  My question is that is it really worth using?  Is it used on the corporate/business level as C++ is?  Do gaming and software development companies use it over C++ now?  etc.

Here are some differences between them what they have/ dont have..

http://www.digitalmars.com/d/

Already read that.  That's where I originally discovered the D language.

Interesting...

My opinion:

1. Don't use it now. Its only compiler (Digital Mars D compiler) is in Alpha and it's still under development. Nothing else supports it and there are no libraries for it.

2. The language looks awesome. It is definitely something to look forward to, as a great replacement (no less!) for C and C++!

That looks awesome!

Seems a bit out of my scope, I'll stick with learning C# for now.

Ew.

They are getting rid of namespaces??? Why???

This seems kinda ewwy, but I will have to wait until there is something before I can judge it.

Maybe they have a better replacement for namespaces. I can't imagine what it would be though...

Namespaces SUCK.

[quote author=rabbit link=topic=11868.msg117092#msg117092 date=1119565647]
Namespaces SUCK.
[/quote]

Elaborate please.

There are a number of things in the D language that I do not like. I'll list the two which I can remember below. The D language *does* look pretty cool with them aside, however. Please feel free to correct me if you think I'm understanding these statements wrong.

[quote]http://www.digitalmars.com/d/function.html#nested
There is no inline keyword. The compiler makes the decision whether to inline a function or not[/quote]So you cannot specifically specify a specific (whoa... lotta specific, heh!) function to be inlined and instead have to hope that the compiler inlines it? Can you say... eww?

[quote]http://www.digitalmars.com/d/class.html
The D compiler is free to rearrange the order of fields in a class to optimally pack them in an implementation-defined manner.[/quote]That's not right, in my opinion. At the very least, there should be an option to turn that off... otherwise, so much for writing an extensible class which directly reads or writes data to or from the network or your hard drive which is compatible with other (and possibly even already-existing) protocols.

[quote author=tA-Kane link=topic=11868.msg117214#msg117214 date=1119599863]
[quote]http://www.digitalmars.com/d/function.html#nested
There is no inline keyword. The compiler makes the decision whether to inline a function or not[/quote]So you cannot specifically specify a specific (whoa... lotta specific, heh!) function to be inlined and instead have to hope that the compiler inlines it? Can you say... eww?[/quote]
I don't agree. Name a situation where you would want to inline a function that the optimizer wouldn't have inlined automatically.
NOTE: Assume the optimizer is smarter than you.

[quote author=tA-Kane link=topic=11868.msg117214#msg117214 date=1119599863]
[quote]http://www.digitalmars.com/d/class.html
The D compiler is free to rearrange the order of fields in a class to optimally pack them in an implementation-defined manner.[/quote]That's not right, in my opinion. At the very least, there should be an option to turn that off... otherwise, so much for writing an extensible class which directly reads or writes data to or from the network or your hard drive which is compatible with other (and possibly even already-existing) protocols.
[/quote]
That refers to classes. The way I understood it, unlike C++, D treats classes and structs very differently. You would use a struct for what you said, not a class, and write C-style functions which accept struct pointers. That is the "systems programming" way to do it; object-oriented programming is much higher level and there is no cross-language way to implement it, currently. (Specifically, C++ classes are already implementation-defined, just like D's are! For example, every compiler implements multiple inheritence differently.)

Edit: As it says later in the same paragraph:
[quote]Explicit control of field layout is provided by struct/union types, not classes.[/quote]

[quote author=Yoni link=topic=11868.msg117246#msg117246 date=1119624749]
[quote author=tA-Kane link=topic=11868.msg117214#msg117214 date=1119599863]
[quote]http://www.digitalmars.com/d/function.html#nested
There is no inline keyword. The compiler makes the decision whether to inline a function or not[/quote]So you cannot specifically specify a specific (whoa... lotta specific, heh!) function to be inlined and instead have to hope that the compiler inlines it? Can you say... eww?[/quote]
I don't agree. Name a situation where you would want to inline a function that the optimizer wouldn't have inlined automatically.
NOTE: Assume the optimizer is smarter than you.[/quote]Without actually extensively testing the D compiler (which I really do not have time for, currently) I cannot provide an example. But I really dislike the idea of not allowing the programmer to specify certain functions to be inlined.

tA-Kane, though I truly believe that the optimizer is better than a human, I see no reason to remove the ability of a programmer to specify inlining.

But that's not enough to keep me from using it. It looks cool.

The part that I consider somewhat strange about the removal of the [u]inline[/u] keyword is that it has always been advisory in C++.  The compiler is free to ignore your inlining request if the function is too complex, is recursive, or is unsuitable for some more obscure reason.  Given that, it seems quite strange to remove manual inlining.

Besides, I've always held the belief that a language shouldn't prevent you from doing something "stupid" if you really think you need to do so.  That doesn't preclude making it difficult to shoot yourself in the foot (e.g. requiring casts or other constructs to assure the compiler you know what you're doing), but it does preclude entirely removing the ability to shoot yourself in the foot.

Anyway, DUI (Driving Under Influence?)
[quote author=dui.sourceforge.net]
DUI is a D language graphical user interface wrapping (or binding) GTK+ graphical toolkit
DUI stands for D graphical User Interface
D can interface with C so any graphics toolkit with a C API can be used directly from D, this includes GTK+.
DUI is released under the LGPL license
[/quote]