I have read many posts saying D was better than C++ as a language but there were no libraries for use case X. Now this may help popularise the language.
D seems like a more useful Rust, or is that completely wrong?
More like D is a Better C.
D Language accepted for inclusion in GCC
51–60 of 235 posts
Re: D Language accepted for inclusion in GCC
#52Earlier quoted context omitted.
By that measure, so do C and C++.
You could implement GC in C++ using RAII (although smart pointers get you a long way). AFAIK, automatic GC is not possible with C.
It absolutely is possible, via conservative GC: https://en.wikipedia.org/wiki/Boehm_garbage_collector
Re: D Language accepted for inclusion in GCC
#53Earlier quoted context omitted.
Those > can be instantiated a finite number of times and then used like non-templated code. So you have a C++ file that uses vector , vector , vector , vector , etc. once and then you can link to them from D code. The only case where that doesn't work is when you have lots of one-off instantiations, where requiring an instantiation in C++ code for each use in D would get annoying quickly.
Does the D compiler know how to mangle/demangle C++ names? Do you have to write some kind of D header file for foreign C++ functions? Otherwise, how would D even know about the existence of e.g. vector ::push?
https://dlang.org/spec/cpp_interface.html#cpp-templates
You will need to recreate the C++ function definitions in D and mark them extern(C++), but that's about it.
Re: D Language accepted for inclusion in GCC
#54I learned about D through Torus Trooper - a highspeed vector graphics game written in D http://www.asahi-net.or.jp/~cs8k-cyu/windows/tt_e.html
That's ye olde D1 though. D2 is a different beast.
Re: D Language accepted for inclusion in GCC
#55Earlier quoted context omitted.
D seems like a more useful Rust, or is that completely wrong?
They are very different languages. Rust was designed to be GC-free and memory safe. D, on the other hand, has GC and is memory unsafe by default.
D being @system by default has already been discussed as a design error, but making @safe be the default would be a breaking change.
So it is up to the community if they want to accept such change.
I should note that they still need some help cleaning the standard library and compiler corner cases in regard to @safe.
Re: D Language accepted for inclusion in GCC
#56Earlier quoted context omitted.
> D understands how C++ function names are "mangled" and the correct C++ function call/return sequence. How does it work in practice ? C++ name mangling is not standardized and so every compiler can implement its own scheme. So does it mean there is a list of D compatible c++ compiler somewhere ? I have the feeling that if you are using some exotic proprietary c++ compiler it won't work well.
In practice there are two dominating standards nowadays, the Itanium ABI and Microsoft's, so it's quite tractable to handle the common cases.
Thanks, I might be biased because I have a legacy platform still using gcc 2.7, which is older than the adoption of the Itanium ABI.
Re: D Language accepted for inclusion in GCC
#57Silly me, I was under the impression that gdc was already part of gcc...
Well, so at least now I am no longer mistaken. ;-)
I have tried to learn D repeatedly over the last couple of years, but I was usually scared off by how complex this language is. Even so, the syntax is far cleaner than C++[1].
Also, the last time I gave it a try, something finally clicked. I am not all there yet, but I am beginning to like it. The community is very friendly and helpful. Being able to ask stupid questions without being shouted at makes learning a language a lot easier.
[1] To be fair, C++ has carried the baggage of backwards compatibility around since its birth, while D did not and could learn from what C++ got right and wrong.
Re: D Language accepted for inclusion in GCC
#58Earlier quoted context omitted.
One of D's goals is to be ABI compatible with C and C++, ABI compatibility with C is 100% as I understand it. C++ is a work in progress. What is ABI compatiblity? in a nutshell it let's you use libraries from another programming language. In D, all you need is a D file that describes the C/C++ library as a wrapper so the D compiler knows what you are using. This means D will build upon everything that already exists…
How would that even work? Modern C++ libraries are largely templates, templates which must be instantiated at compile-time i.e. you need a full C++ compiler to use C++ libraries directly. Said compiler must somehow work together with the D compiler here, which should lead to god-awful memory use, compilation time, and error messages.
You can port some of the templates to D, since it also has templates. Although I'm not sure if they work the same in all pathological cases.
Re: D Language accepted for inclusion in GCC
#59Earlier quoted context omitted.
In my experience, D is like more powerful and feature-packed C#. It doesnt impose any limitations on you and your coding style/paradigm and strives to be "the one to rule them all" tool which has everything and can be used for everything from scripting to systems programming (when stdlib will be more @nogc friendly). And yes, templates are so much better in D than in C++ or in C# :)
> when stdlib will be more @nogc friendly How does @nogc work in D? Is it easy to keep track of what needs freeing and what does not or is it easy to mix up and get hard bugs? Also, what do these bugs look like? Is use-after-free possible or how is the failure mode i that case? Is it possible to call free on an object after it's been garbage collected?
@nogc just causes the compiler to error out when a GC allocation occurs in the region marked @nogc and its call graph. You are then expected to manage memory yourself. You could rename it @c_or_cpp_style_memory_management_only. You can malloc/free (scope(exit) is useful here), use smart pointers, alloca, static arrays, use Andrei's allocators[1], or whatever else you'd use in C or C++.
The answer to all of your questions is basically the same as they are in C and C++. D does have @safe though which prevents unsafe memory operations and Walter is in the process of ratcheting up the memory safety with DIP1000[2].
1. https://dlang.org/phobos/std_experimental_allocator.html 2. https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md
Re: D Language accepted for inclusion in GCC
#60Earlier quoted context omitted.
How would that even work? Modern C++ libraries are largely templates, templates which must be instantiated at compile-time i.e. you need a full C++ compiler to use C++ libraries directly. Said compiler must somehow work together with the D compiler here, which should lead to god-awful memory use, compilation time, and error messages.
You should probably read up on ABI Compatibility, and, Compiling vs linking as well. Let's be clear a compiler builds a object files that have to be linked to create a executable binary. IE compiler makes .o files. Linker takes output object files from the compiler an puts them (.o,.so/.dll,.a) together, to make .exe files. This all works because you are linking to the C/C++ library binaries (the .o, .so, .a, .dll) f…
That's not really relevant to their question. Many templates are implemented via inlining/instantiation in client code by default, and as such they won't be present in the output of the C++ compiler.