about D programming

04/03/2012 21:00 injection illusion logic#1

what is d ?
http://en.wikipedia.org/wiki/D_(programming_language)
any tut for d ?
[Only registered and activated users can see links. Click Here To Register...]
[Only registered and activated users can see links. Click Here To Register...]

useful links ?
[Only registered and activated users can see links. Click Here To Register...]

features ? almost all but mult. inheritance and dclass loading
[Only registered and activated users can see links. Click Here To Register...]

Why doesn't D have an interface to C++ as well as C?

Spoiler

Quote:

D 2.0 does have a limited interface to C++ code.

Here are some reasons why it isn't a full interface:
Attempting to have D interface with C++ is nearly as complicated as writing a C++ compiler, which would destroy the goal of having D be a reasonably easy language to implement. For people with an existing C++ code base that they must work with, they are stuck with C++ (they can't move it to any other language, either).

There are many issues that would have to be resolved in order for D code to call some arbitrary C++ code that is presumed to be unmodifiable. This list certainly isn't complete, it's just to show the scope of the difficulties involved.

D source code is unicode, C++'s is ASCII with code pages. Or not. It's unspecified. This impacts the contents of string literals.
std::string cannot deal with multibyte UTF.
C++ has a tag name space. D does not. Some sort of renaming would have to happen.
C++ code often relies on compiler specific extensions.
C++ has namespaces. D has modules. There is no obvious mapping between the two.
C++ views source code as one gigantic file (after preprocessing). D sees source code as a hierarchy of modules and packages.
Enum name scoping rules behave differently.
C++ code, despite decades of attempts to replace macro features with inbuilt ones, relies more heavily than ever on layer after layer of arbitrary macros. D does not always have an analog for token pasting and stringizing.
Macro names have global scope across #include files, but are local to the gigantic source files.
C++ has arbitrary multiple inheritance and virtual base classes. D does not.
C++ does not distinguish between in, out and ref (i.e. inout) parameters.
The C++ name mangling varies from compiler to compiler.
C++ throws exceptions of arbitrary type, not just descendants of Object.
C++ overloads based on const and volatile. D overloads based on const and immutable.
C++ overloads operators in significantly different ways - for example, operator[]() overloading for lvalue and rvalue is based on const overloading and a proxy class.
C++ overloads operators like < completely independently of >.
C++ does not distinguish between a class and a struct object.
The vtbl[] location and layout is different between C++ and D.
The way RTTI is done is completely different. C++ has no classinfo.
D does not have two phase lookup, nor does it have Koenig (ADL) lookup.
C++ relates classes with the 'friend' system, D uses packages and modules.
C++ class design tends to revolve around explicit memory allocation issues, D's do not.
D's template system is very different.
C++ has 'exception specifications'.
C++ has global operator overloading.
C++ name mangling depends on const and volatile being type modifiers. D name mangling depends on const and immutable being type modifiers. D's const is also transitive, unlike C++. One cannot have a const pointer to mutable in D.

FAQ ? [Only registered and activated users can see links. Click Here To Register...]

wish this was helpful o-0

04/03/2012 22:27 KraHen#2

Actually I don`t like this language for some reason. I realize that it has it`s uses, I can certainly see how it can be useful, but just like with Actionscript, I somehow don`t like it the way I like C++ or C#, or even Java. For instance... type casting? cast(ubyte)? Lol? This is only personal preference though.

04/07/2012 19:58 I don't have a username#3

You don't want to use D and this is why:

Quote:

Originally Posted by cinik

To be honest, I never liked idea of D, it's still not good enough to be substitution for C/C++ and it will never be. MS is standing behind .net/C++, open source community still support C/C++/Java/Python/Haskell/... name it, and there is not enough space for D to fit in and become mainstream. Each of these programming languages has it's own use and it's still mainly used in IT, D is supposed to come as ultimate solution/answer to all the features these programming languages lack. Digital Mars has not enough power to propagate D among users, even shitty VBS got more programmers than D and MS didn't quit its support, VBS is still being supported on every windows, including win8. So, nope, stick to C/C++/C# or anything I named above, you won't make mistake. D is just dead end.[hr]
Why Intel Itanium died? It was fairly a good solution, nice processor archicteture, why don't people move to x64, there is still a shitload of people using old windows xp. You can't create standard by just offering "better solution, claiming that your X has better features than Y" and hope people will buy into that. People just want what is easy to use, popular, can get the shit done, and that's all. So, yeah, once again, choose C/C++.[hr]
Considering there are so many applications coded in C/C++ it would be kinda dumb to move "something else". All that code needs to be maintained, patched, recoded, I don't think that C++/C will "die" in next 20 years. Its standard will surely be redefined, you have C11 now, but there are still no compilers that support any of those features. MSVC support only C89 ;). And I personally don't see anything really "amazing" that would D offer instead C++.

Note this is not from this forum... But me asking about it in another forum.