12 ms·
D 2.069.0 released, compiler automatically ported from C++ to D
- WalterBright 11y agoDaniel Murphy is the man behind getting the sources converted from C++ to D. He wrote a program called "magicport" to do the bulk of it, with some manual tweaking. The back end is still in C++, showing that you can mix D and C++ code :-)
- lazyjones 11y agoHow is the compiler bootstrapped now (i.e. compiled from source without a working D compiler)? Via the gcc D implementation?
- pjmlp 11y agoIf my information is still actual, the last C++ based implementations will be used for the time being for such purposes.
- Zardoz84 11y agoUsing the previous version write on C++. Like all compilers of other languages did when change to be write on his own language. Or do you think that the first version of C compiler was write on C ?
- pjmlp 11y agoFunny anecdote for compiler researchers. Niklaus Wirth did write many of his compilers in the original language (kind of). He would write down on paper the code, using the bootstrap version 0 code style, as it was supposed to be. Then he would manually translate that code into Assembly. So when the compiler for the basic language was working, he could use the same code again, without additional efforts and relying on third party languages. Specially important back in the day where each computer system had its own systems programming language or dialect of an existing one.
- WalterBright 11y agoComputer languages were a lot simpler in those days.
- pjmlp 11y agoAre you sure? I remember reading something about PL/I. :)
- epoch1970 11y agoWalter has been around a long time. He knows the game. Walter, have you ever used PL/I?
- pjmlp 11y agoI have spent quite some time in D forums.... EDIT: typo, time was missing
- WalterBright 11y agoNope. But Pascal was so simple that a listing for a working subset compiler for it (written in BASIC) was published in BYTE magazine back in the 70s. But I (and many other compiler devs) thought back in the early 80's that Ada was so complex it was unimplementable. Today that thought seems charmingly naive.
- nickpsecurity 11y agoMaybe PL/S, IBM's "secret weapon," (haha) would be better if we're talking C++ replacements. I did like how the language let you describe how exactly the compiler should handle the individual function. I can see that have payoff in OS and security-critical software. https://en.wikipedia.org/wiki/IBM_PL/S https://en.wikipedia.org/wiki/IBM_PL/S
- pjmlp 11y agoInteresting, I wasn't aware of it.
- lazyjones 11y agoThat's not really the only possible way. You could write an (arbitrarily slow & simple) interpreter in e.g. C to compile the compiler with itself, or translate to C, or use something like a p-code machine as an intermediate step (https://en.wikipedia.org/wiki/P-code_machine https://en.wikipedia.org/wiki/P-code_machine) with an assembler-written interpreter. The problem with using older versions is that in principle, you'd have to keep maintaining/porting them for newer systems/architectures.
- rogeryu 11y agoNow all we need is some E to celebrate!
- qznc 11y agohttps://en.wikipedia.org/wiki/E_(programming_language) https://en.wikipedia.org/wiki/E_(programming_language)
- chubot 11y agoHm this sounds just like the port of the Go compiler from C to Go. In that case it was C and Go, rather than C++ and D.
- amelius 11y agoI'm wondering, is there an advantage of using D over Rust?
- scardine 11y agoI guess D feels more like a better C++ and Rust like a better C, but I may be under the wrong impression.
- humanrebar 11y agoRust is more like the child of C and a functional language (OCaml).
- acz 11y agoStill think that *ML syntax would fit Rust better.
- royjacobs 11y agoHow would you consider Rust's generics as being part of a better C rather than a better C++?
- johncolanduoni 11y agoI think it's more about Rust's approach to OO. In Rust, traits are usually used as interfaces for generics instead of dynamic dispatch. The generated code/performance is more like what you would get if you implemented them explicitly for each appropriate type in C, built around structs. You could do this with C++ templates, but it would be a huge pain in that language due to lack of template type safety. This is a quite important part of Rust (IMHO) because it gives the language a performance profile closer to C than C++ in many instances.
- royjacobs 11y agoHmm, I see your point, but I've found that even in template-heavy code the compiler can produce code that's pretty optimal. Are you saying that with Rust it is easier to fall into the pit of success, as it were -- requiring less reasoning about how a compiler might convert the [templated|generic] code optimally?
- 505 11y agodanmurphys.com.au
- AsyncAwait 11y agoHow's the memory-safety model in D without a GC, last time I looked at it, it seemed to me that C++ 11/14 has the better model here and now with the C++ core guidelines, it may be even better.
- qznc 11y agoCould you elaborate? What about the C++ 11/14 model improves memory safety?
- pjmlp 11y agoI imagine he/she means the newly introduced C++ Core Guidelines with the _prt<>() and _view() classes, and the adoption of Rust like lifetime analysis for static analysers.
- pjmlp 11y agoCurrently it still relies on the GC. However you can write gc free code regions by marking them as @nogc and the compiler will make sure you only call code that is @nogc compatible. Additionally, there is some ongoing discussion how to improve the language to depend less on the GC. The C++ core guidelines are great, and me being a C++ fan even with its warts, welcome them and all the work the C++ community is doing. However them being opt-in, relying on static analysis and the quality of the code I usually see at companies, which tends to be C with Classes from developers that don't even know what CppCon is, I am not sure how the adoption will be like.
- slacka 11y agoHas the core guidelines Checker tool been released yet? For those that haven't studied the guideline intensely, I'd assume it's necessary to do any kind of real world comparison.
- ogezi 11y agoD is a really amazing language that manages to correct the mistakes of c++ but still retain its good parts. it's a shame that it's not more popular.
- yokohummer7 11y agoTo me, while D fixes many warts of C++, D is still too similar to C++ to justify the change. It still has implicit numeric cast, exception unsafety and strange behaviors.[1] In addition, the D authors are generally opposed to disciplined approaches, e.g. type classes, region-based memory management, which are being added to C++. Especially regarding the former, while "design by introspection" may have its merits (Andrei Alexandrescu's presentation on allocator is worth watching[2]), I think many still prefer explicit interfaces over implicit ones, so I don't see D take off in the near future, at least until the wanted features are added to the language. [1] http://forum.dlang.org/thread/htmkdnmlqyvkidkrsmri@forum.dlang.org http://forum.dlang.org/thread/htmkdnmlqyvkidkrsmri@forum.dla... [2] https://www.youtube.com/watch?v=mCrVYYlFTrA https://www.youtube.com/watch?v=mCrVYYlFTrA
- WalterBright 11y ago> It still has implicit numeric cast, Implicit numeric casts that lose bits are not allowed anymore. > exception unsafety ??
- yokohummer7 11y ago> Implicit numeric casts that lose bits are not allowed anymore. That's good to hear, but I want implicit conversion to be forbidden unconditionally (even int * float -> float). I've been bitten by even widening conversions, so I just want to let them go away. It might be great if such an option could be applied to module level. > ?? Sorry if my understandings or my words were wrong, but I got the impression that D also suffers from destructors that throw. (double-throw) Is this not the case in D? If so, could you elaborate how it achieves that? I'm personally rather fond of purging exceptions from the language level completely, like Go did(Of course panics are technically exceptions, but their usage is culturally discouraged). Of course, this is just my personal opinion, but I would be happy if D had a story on this problem.
- thepumpkin1979 11y agoNot sure what I do wrong every time I try D again, I wanted to see the new backtraces worked but I still get: /bin/bash: line 1: 82501 Segmentation fault: 11 ./main while I try to call a method on a null variable, which is not that friendly to newcomers. Sample code: import std.stdio; void main() { Greetings g = null; g.hola(); }
- trishume 11y agoDid you compile with debug info (-g I think)? It needs to read the DWARF info to get the line numbers.
- thepumpkin1979 11y agoI think so: $ dmd -g main.d && ./main Segmentation fault: 11 is there anything else I can try? I'm OSX El Capitan 10.11.1
- lultimouomo 11y agoOn Unix segfaults by default don't generate stack traces. This makes it work on linux, don't know about OSX (put it in your main module): import etc.linux.memoryerror; shared static this() { static if (is(typeof(registerMemoryErrorHandler))) registerMemoryErrorHandler(); }
- thepumpkin1979 11y agoThe handler works in a real ubuntu VM but not in docker (the image is probably missing glibc https://github.com/D-Programming-Language/druntime/blob/master/src/etc/linux/memoryerror.d#L17 https://github.com/D-Programming-Language/druntime/blob/mast... so that explains "static if" in your snippet) to be honest, it's better than nothing but still kinda difficult to work with: etc.linux.memoryerror.NullPointerError@src/etc/linux/memoryerror.d(325) ---------------- ??:? void etc.linux.memoryerror.sigsegvUserspaceProcess(void*) [0x439045] ??:? void etc.linux.memoryerror.sigsegvDataHandler() [0x438f92] ??:? _Dmain [0x435c17] ??:? _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv [0x4376da] ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) [0x437630] ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll() [0x437696] ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) [0x437630] ??:? _d_run_main [0x43758d] ??:? main [0x436075] ??:? __libc_start_main [0xb0fa1ec4]
- deleted 11y ago[deleted]
- tinco 11y agoThose sorts of transpilers are usually tailored to a specific project, so it would probably not work on bitcoin-core. Of course if bitcoin-core was committed to moving to D they could fork the transpiler and tailor it to their own code base.
- SamReidHughes 11y agoI have no idea what the GP post said, but even if it did work, see patio11's comments (on the internet) on the need to reproduce bitcoin-core's behavior exactly.
- aidenn0 11y agoThis is the first time I found out that DMD isn't self-hosting; I always assumed it was.
- nickpsecurity 11y agoMe too. Figure something good enough to replace C++ immediately and better to develop with would make for a better compiler. Not to mention all the advantages of writing a compiler in the language in question. Only exception I promote is writing compilers in ML (esp Ocaml) because it's so good at doing that correctly. A concentration of compiler writers on such a great tool can only lead to an ecosystem whose quality C or C++ compilers will have trouble matching. Rewriting and testing the LLVM system at the least would be a good thing.