81–90 of 235 posts
Earlier quoted context omitted.
I think they meant lower case "open source" (as in the source is open (anyone can read/compile it)). There are plenty of software that are open source but not freely distributable, such as Unreal Engine.
The usual term for that sort of arrangement would be "shared source".
Earlier 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.
While I like D and use it for scientific work, wwo "omissions" leave me a bitter taste. Nothrow and Pure are not part of the type signature of functions and consequently the compiler has limited inference about these. However I will keep using it unless something better comes up. C++/C# are not an option for me since I found D.
Earlier 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 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.
That's really great news and ensures long term viability of the D language and associated eco system.
What does it bring over modern C++? Why would you want to use it?
Earlier quoted context omitted.
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 how C++ templates work. You cannot deliver them as binaries. Templates are delivered as C++ include files (i.e. source code). When you use them, the compiler fills in the types you want and compiles the result. For example, there's the std::vector template. You can fill in any type that meets the specific requirements of the template and use it like std::vector or std::vector . However, you probably won't…
Also if your "library" is all templates, it's not a library, it's a framework that uses other libraries. There still has to be at some point tangible code that is compiled to an object file to be linked. You will have to find all of the dependancies and make sure that they are also described in a .d file.
This might mean you have a bunch of work that you need to do in order use the c++ code you want to bring in into D. But then again, if it's a public/open source library, and you go down that rabbit hole and make it work, you just made D even better.
please see https://dlang.org/spec/cpp_interface.html#cpp-templates for more details.
This is basically the work of one tireless man; Iain Buclaw. Many thanks to him for putting in so much time and energy into this. It took 6 years from first submission to get it in. Here are the slides from his 2017 DConf talk about the work that went into making this happen: http://dconf.org/2017/talks/buclaw.pdf