Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

D Language accepted for inclusion in GCC

gcc.gnu.org

Post reply on HN
Print view View original

61–70 of 235 posts

Re: D Language accepted for inclusion in GCC

#61

Post by microtonal »

iamNumber4 wrote: post #47
copx wrote: post #15

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 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…

I think you misunderstood your parent. A lot of modern C++ 'libraries' are header-only, because they heavily use templates. There is no object code or library to link against until you instantiate templates.

Re: D Language accepted for inclusion in GCC

#62

Post by enzo1982 »

iamNumber4 wrote: post #47
copx wrote: post #15

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 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 be able to do std::vector. ABI compatibility is not enough to do this as you would be effectively mixing C++ and D source code here.

Re: D Language accepted for inclusion in GCC

#64

Post by timlyo »

yorwba wrote: post #31
joobus wrote: post #18

Earlier quoted context omitted.

D is garbage-collected, but can be opted out of. Rust has no garbage collector.

Rust has an opt-in garbage collector as a library ( https://docs.rs/gc/ ). I don't know how good it is, though.

What's the use case for a garbage collector in rust?

Re: D Language accepted for inclusion in GCC

#65

Post by syockit »

boondaburrah wrote: post #29
amyjess wrote: post #27

Earlier quoted context omitted.

> The reference backend was only Open Source (not freely redistributable). Free redistributibility is part of the Open Source Definition. It is literally the first item: https://opensource.org/osd-annotated

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 first time I said that on HN somewhere else I got quite a flak. I don't know when OSI's definition became mainstream. The first time I heard open source, it meant the same as what you said. Nowadays you have to use a different term for that.

Collins still has the old definition "free to use or modify". Merriam-Webster and Oxford has since included "redistribution" in the definition.

The term "shared source" is not in any dictionary though.

Re: D Language accepted for inclusion in GCC

#66

Post by jpf91 »

jjnoakes wrote: post #43
jpf91 wrote: post #42

Earlier quoted context omitted.

Likely none. Well, I guess that's kind of an oversimplification though so here's the detailed story: We require some per-target integration to provide correct version(ARM), version(linux) statements in D code and we need to know the size of a mutex on the target system. Iain is currently rewriting this code here: https://github.com/D-Programming-GDC/GDC/pull/500 However, we already provide and the new, rewritten code…

Glad to hear there's work in progress. Last time I tried to configure gcc + gdc on AIX on PowerPC, I found out it was explicitly disabled in the configure script, and I didn't dig any deeper to find out why or the potential work involved.

I guess that was quite some time ago?

Back then we had a shell script hack that was called by the GCC configure script and parsed the target triplet to set these versions.

Fortunately that's long gone and we now simply add some D specific code to the platform configuration files in gcc/config/ . The shell script hack would have never passed the GCC review ;-)

Re: D Language accepted for inclusion in GCC

#67

Post by eco »

liveoneggs wrote: post #25
afghanPower wrote: post #12

Earlier quoted context omitted.

D seems like a more useful Rust, or is that completely wrong?

D is like Go if Go had actually been a "systems" programming language. Rust is difficult to compare to other stuff.

How do you figure? D is C++ with lessons learned. I mean, it's right there in the name. I find very few similarities between Go and D. Also, D is much older than Go so if anything Go would be D if D decided to not be a "systems" programming language (but it's plainly obvious that isn't the case).

Re: D Language accepted for inclusion in GCC

#68

Post by acehreli »

liveoneggs wrote: post #25
afghanPower wrote: post #12

Earlier quoted context omitted.

D seems like a more useful Rust, or is that completely wrong?

D is like Go if Go had actually been a "systems" programming language. Rust is difficult to compare to other stuff.

To me, D's compile-time features like templates, code generation, etc. are some of its most important features. Lacking those and exceptions and many other useful bits, Go cannot compare to D. (I finally can claim experience on both languages after having coded Go for about a month.)

Re: D Language accepted for inclusion in GCC

#69

Post by jpf91 »

enzo1982 wrote: post #62
iamNumber4 wrote: post #47

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…

> However, you probably won't be able to do std::vector. ABI compatibility is not enough to do this as you would be effectively mixing C++ and D source code here.

I think this should be working. You don't have to 'mix source code', you can implement YourDClassType in D and use it in C++. You simply have to write a C++ header describing the class. Then write a D file describing the external C++ sdt::vector file and link everything together.

Not sure if anybody actively tested this though ;-)

Re: D Language accepted for inclusion in GCC

#70

Post by le-mark »

dbcurtis wrote: post #6
LukeShu wrote: post #2

There has been out-of-tree GCC support for D for several years. I wonder what has changed that they're letting it in to the official repository.

My guess is that is also why. gcc wants to be assured there are sufficient maintainers. If a crew has been maintaining out-tree-support with a good track record, that demonstrates maintainability.

Is this what happened to gcj, lack of maintainers? I always thought it was a shame support for it lapsed, a to native java compiler would be awefully nice to have.
Post reply on HN