DigitalMars C/C++ Compiler(github.com)
github.com
DigitalMars C/C++ Compiler
https://github.com/DigitalMars/Compiler/tree/master/dm/src/dmc
157 comments
This is absolutely awesome. Until now, the DM C/C++ compiler was closed-source freeware, with contracting/consulting available (https://digitalmars.com/consulting.html). This makes things 10x as amazing :)
Also related is that D is now completely under the Boost license as well.
Historically D was "partially open, partially closed"; the D frontend (syntax parser and some other pipeline stages) was open, but the backend/code-generator was built on top of the Zortech C++ compiler for DOS/Windows/OS/2. (I only have a hazy notion of the Datalight>Zorland>Zortech>Symantec transition; I'll bet the story would make for an awesome history book, if that doesn't already exist. Hint)
There was (highly appropriate) major fanfare when Symantec, who bought Zortech in Aug 1991, allowed the compiler backend technology to be open-sourced in April 2017, 1 year and 1 month ago: https://news.ycombinator.com/item?id=14060846
And that, fairly clearly, is what made this source release possible. Also https://news.ycombinator.com/item?id=17131274 :)
References (most insightful first):
- http://www.edm2.com/index.php/Zortech_C%2B%2B
- https://en.wikipedia.org/wiki/Digital_Mars
- http://www.computinghistory.org.uk/det/10940/Zortech%20C/
- http://www.edm2.com/index.php/Symantec_C%2B%2B
Also related is that D is now completely under the Boost license as well.
Historically D was "partially open, partially closed"; the D frontend (syntax parser and some other pipeline stages) was open, but the backend/code-generator was built on top of the Zortech C++ compiler for DOS/Windows/OS/2. (I only have a hazy notion of the Datalight>Zorland>Zortech>Symantec transition; I'll bet the story would make for an awesome history book, if that doesn't already exist. Hint)
There was (highly appropriate) major fanfare when Symantec, who bought Zortech in Aug 1991, allowed the compiler backend technology to be open-sourced in April 2017, 1 year and 1 month ago: https://news.ycombinator.com/item?id=14060846
And that, fairly clearly, is what made this source release possible. Also https://news.ycombinator.com/item?id=17131274 :)
References (most insightful first):
- http://www.edm2.com/index.php/Zortech_C%2B%2B
- https://en.wikipedia.org/wiki/Digital_Mars
- http://www.computinghistory.org.uk/det/10940/Zortech%20C/
- http://www.edm2.com/index.php/Symantec_C%2B%2B
Apparently, the compiler is progressively rewritten in d. For those interested, there is a tag for the last pure c version: https://github.com/DigitalMars/Compiler/tree/Last-C-Version
Would probably be interesting to convert it in C++17 :-)
Meta-comment: I delete my previous comment by error and want to put it again, and didn't manage to do it again. Is there some anti-duplication code that prevent to write 2 times the same comment on HN?
Would probably be interesting to convert it in C++17 :-)
Meta-comment: I delete my previous comment by error and want to put it again, and didn't manage to do it again. Is there some anti-duplication code that prevent to write 2 times the same comment on HN?
> Apparently, the compiler is progressively rewritten in d.
Can confirm, that's what I'm doing. Most of the code is written in an old-fashioned style, but rather than redo that, it's more productive to convert to D, and then into a modern style.
The D conversion as it stands is by rote translation, thereby retaining the technical debt. I don't plan on improving the structure until it is all in D.
Can confirm, that's what I'm doing. Most of the code is written in an old-fashioned style, but rather than redo that, it's more productive to convert to D, and then into a modern style.
The D conversion as it stands is by rote translation, thereby retaining the technical debt. I don't plan on improving the structure until it is all in D.
If I may ask, why did you opt to port the code in that order (translate -> re-architect)? I suspect you have experience in this, and I was curious what experience taught you.
Edit: Answered below in "May it have been better to start from scratch?"
Edit: Answered below in "May it have been better to start from scratch?"
Not Walter Bright, but I'm pretty sure it minimizes the chances for new bugs. You do a dumb conversion that tries to minimize the actual code changes, check that works ok, then start making larger changes.
https://www.joelonsoftware.com/2002/01/23/rub-a-dub-dub/
> 1. No New Features, not even small ones, would be added.
> 2. At any time, with any check in, the code would still work perfectly.
> 3. All I would do is logical transformations — the kinds of things that are almost mechanical and which you can convince yourself immediately will not change the behavior of the code.
https://www.joelonsoftware.com/2002/01/23/rub-a-dub-dub/
> 1. No New Features, not even small ones, would be added.
> 2. At any time, with any check in, the code would still work perfectly.
> 3. All I would do is logical transformations — the kinds of things that are almost mechanical and which you can convince yourself immediately will not change the behavior of the code.
Thank you so much, Walter, for creating such a great language! I'm now coding mostly in D, and it's a joy to use. It's expressive and powerful, but at the same time really fast. I regret not giving it a chance earlier.
Glad it's working for ya!
Most of the code is written in an old-fashioned style, but rather than redo that, it's more productive to convert to D, and then into a modern style.
I'm not sure what exactly you have in mind for "modern style", but I found the code as it is to be quite readable and a breath of fresh air from a lot of other code I've heard referred to as "modern" (which seems to mostly mean laboriously long identifiers, excessive amounts of abstraction, and CamelCaseScreamingAtYouEverywhere.)
I'm not sure what exactly you have in mind for "modern style", but I found the code as it is to be quite readable and a breath of fresh air from a lot of other code I've heard referred to as "modern" (which seems to mostly mean laboriously long identifiers, excessive amounts of abstraction, and CamelCaseScreamingAtYouEverywhere.)
Excessive use of global state, poor encapsulation, leaky abstractions, generally clumsy code.
It is bad enough that I considered not open sourcing it for fear of damage to my career :-) but then decided what the hell.
The good thing about the DMC++ source code is, it works. You can make anything work if you invest enough effort into it.
It is bad enough that I considered not open sourcing it for fear of damage to my career :-) but then decided what the hell.
The good thing about the DMC++ source code is, it works. You can make anything work if you invest enough effort into it.
This is great, are there some intended goals for having a C++ compiler written in pure D after you've started to improve the structure? I'm thinking of things like the faster C++ preprocessor that was done for Facebook in D (was it Warp?) and similar improvements to C++ through D.
Thanks for all your awesome hard work by the way!
Thanks for all your awesome hard work by the way!
I don't really have any scathingly brilliant goals for the D version, other than inspiring others to make use of it. I still maintain it, it'll be much easier to maintain in D, and not much work to convert it to DasBetterC.
Yes, it was Warp:
https://github.com/facebookarchive/warp
https://code.facebook.com/posts/476987592402291/under-the-ho...
You're welcome! It's reactions like yours that make it worthwhile.
Yes, it was Warp:
https://github.com/facebookarchive/warp
https://code.facebook.com/posts/476987592402291/under-the-ho...
You're welcome! It's reactions like yours that make it worthwhile.
Thanks for your hard work.
Can you please add, if you have time, a few lines (the commands required) for building the compiler from source ?
Can you please add, if you have time, a few lines (the commands required) for building the compiler from source ?
make clean
make scppnThanks, I've installed DMD and DMC, when I try to build the compiler I get a compilation error:
.\code.d(16): Error: module `cc` is in file 'ddmd\backend\cc.d' which cannot be readSeems I haven't tried to build it from the github in a while. code.d was missing from the makefile command to update github. Fixed.
Previous error is now fixed.
New error:
dmd -c -betterC -noboundscheck -mv=dmd.backend=. -mv=tk=tk -version=SCPP -O -release -inline dt.d -ofdth.obj dt.d(36): Error: TypeInfo cannot be used with -betterC
--- errorlevel 1
--- errorlevel 1There are probably better ways to do this.
Hmm, looks like you're using the latest dmd. I've been using 2.074. I suggest switching to 2.074, or wait until I get it working properly with the latest dmd.
I've checked with 2.074.0 and 2.074.1, no joy, but a new error:
BTW, I did all my tests on a clean Windows machine with nothing else installed.
dmd -c -betterC -noboundscheck -mv=dmd.backend=. -mv=tk=tk
-version=SCPP -O -release -inline -J. dfile.dBTW, I did all my tests on a clean Windows machine with nothing else installed.
I don't know why that is happening on your setup. You can try replacing 'stream' on the next line with 'stdout', and remove the enum declaration.
Yes, I've tried to build dmc using the latest dmd. I will try with 2.074 and report back
That's good to hear! Please don't stop working on D ever, it really is a fantastic gem in a sea of programming languages. My only regret is not using it in production more (decisions out of my control).
I'll be working on it until they carry me out in a box.
Automated Teller ATM Machine
If you are also confused by the title, DMC = DigitalMars Compiler. It is a C/C++ compiler which seems to be almost completely written by one person
https://en.wikipedia.org/wiki/Digital_Mars
If you are also confused by the title, DMC = DigitalMars Compiler. It is a C/C++ compiler which seems to be almost completely written by one person
https://en.wikipedia.org/wiki/Digital_Mars
He is also the only person who has ever written an entire C++ compiler on their own, in addition to the first direct-from-C++ compiler. Cfront was a transpiler.
I suspect that both Tom Pennello and Chris Lattner would also qualify by your criteria.
Chris Lattner as the primary builder of LLVM deserves enormous credit for that work. Did he really write the entire C++ compiler himself?
I haven't been able to find much on Tom Pennello besides some parsing papers from the 70s... I'm interested, but don't know how to find more about his work.
I haven't been able to find much on Tom Pennello besides some parsing papers from the 70s... I'm interested, but don't know how to find more about his work.
One name to look for is MetaWare.
[deleted]
According to the comments it's a D compiler, not C++, but your point still stands.
DMC is in fact a C/C+ compiler (from what I can tell; I don’t use it personally). The D compiler is called DMD.
That is correct. DMC is more precisely a C++98 compiler, with a few later additions.
I'm curious why the source files I randomly picked to skim over all had this at the top:
* Compiler implementation of the
* $(LINK2 http://www.dlang.org, D programming language).The optimizer and back end are shared between DMC and DMD.
Where is the DM C runtime code? I haven't found it.
Do you have plans to bring it up to date with the current C++ standard?
I don't have the time to. I'm always overcommitted :-(
I would put up big money for a shirt that said "Run DMC++" and had the Digital Mars icon on it.
Great idea! Wish I'd thought of it. But then, I'd get sued by Run DMC :-(
GCC has also joined in the fun: https://www.fsf.org/blogs/gnu-press/gnu-press-releases-run-g...
What are you replying to? The title doesn't use 'DMC'?
Before it was edited, the title was "DigitalMars DMC Compiler"
Walter here. AMA.
How does it feel having your "life's work"[1] becoming big enough to be noticed, but ignored by the mainstream?
You created the first "better C" out there to get any traction, it had a perfect name (B -> C -> D), but due to factors that were partially [2] outside your control [3], D's niche got eaten by Go and Rust.
[1]. The D programming language. [2]. I've seen people blaming the D to D2.0 transition, but D was a niche language before too. I've also seen people blame D for not having an Open Source compiler for years, but neither did Java, and it took off anyways. [3]. Such as Sun's marketing, or the general push to scripting languages between 1995-2010 (such as perl, tcl, PHP, Ruby, Python and Node)
You created the first "better C" out there to get any traction, it had a perfect name (B -> C -> D), but due to factors that were partially [2] outside your control [3], D's niche got eaten by Go and Rust.
[1]. The D programming language. [2]. I've seen people blaming the D to D2.0 transition, but D was a niche language before too. I've also seen people blame D for not having an Open Source compiler for years, but neither did Java, and it took off anyways. [3]. Such as Sun's marketing, or the general push to scripting languages between 1995-2010 (such as perl, tcl, PHP, Ruby, Python and Node)
When I started, I was well aware of:
"Certainty of death. Small chance of success. What are we waiting for?"
https://www.youtube.com/watch?v=8joT0oFuGoI
For a language without a megacorp pushing it, D is spectacularly successful. Consider:
1. It's developed by volunteers who work on it for the joy of it without remuneration.
2. People who spend the effort to get past the learning curve find it very pleasing and productive.
3. Other major languages have been continuously copying D's features :-)
4. Corporations that have adopted it for mission critical use have told me that D is their "secret weapon" that allows them to out-maneuver and out-innovate their competitors.
It's like the music business - you don't have to be the Beatles to have a very good career.
"Certainty of death. Small chance of success. What are we waiting for?"
https://www.youtube.com/watch?v=8joT0oFuGoI
For a language without a megacorp pushing it, D is spectacularly successful. Consider:
1. It's developed by volunteers who work on it for the joy of it without remuneration.
2. People who spend the effort to get past the learning curve find it very pleasing and productive.
3. Other major languages have been continuously copying D's features :-)
4. Corporations that have adopted it for mission critical use have told me that D is their "secret weapon" that allows them to out-maneuver and out-innovate their competitors.
It's like the music business - you don't have to be the Beatles to have a very good career.
Walter, I have been using your products way back since before Zortech, at the time it was the only C++ system that I could get to work with the Phar Lap DOS extender to create big binaries.
Thank you for all your hard work, your products formed the center on my early career, and most of what i know i learned using your tools.
Note I particularly loved "Zed" the text editor that came with the early toolchain.
Regards Tim Hawkins, a grateful hacker.
Thank you for all your hard work, your products formed the center on my early career, and most of what i know i learned using your tools.
Note I particularly loved "Zed" the text editor that came with the early toolchain.
Regards Tim Hawkins, a grateful hacker.
Welcs!
> It's like the music business - you don't have to be the Beatles to have a very good career.
I think you're too humble here. The quality of D is no lower than the competing products backed by huge corporations.
I also vaguely remember using Symantec C++, it was a refreshing alternative to the competitors of the time, and I had very pleasant experience using it.
I think you're too humble here. The quality of D is no lower than the competing products backed by huge corporations.
I also vaguely remember using Symantec C++, it was a refreshing alternative to the competitors of the time, and I had very pleasant experience using it.
> It's like the music business - you don't have to be the Beatles to have a very good career.
That is an inspired quote. I shall steal that and use it whenever anyone argues "why x when y already exists".
That is an inspired quote. I shall steal that and use it whenever anyone argues "why x when y already exists".
>whenever anyone argues "why x when y already exists".
Yes, seen many people argue that, including to me, e.g. about some of my blog posts, which show hand-rolled ways of doing things when a library for that exists. I guess often such people are not doing anything much themselves, and don't get that people can create something in the same area where something else exists, for any number of reasons, even just for sheer fun, love of the field, or for teaching beginners.
Yes, seen many people argue that, including to me, e.g. about some of my blog posts, which show hand-rolled ways of doing things when a library for that exists. I guess often such people are not doing anything much themselves, and don't get that people can create something in the same area where something else exists, for any number of reasons, even just for sheer fun, love of the field, or for teaching beginners.
> "Certainty of death. Small chance of success. What are we waiting for?"
You are an inspiration Walter !!
You are an inspiration Walter !!
My favorite line from the movie.
> It's like the music business - you don't have to be the Beatles to have a very good career.
For someone who is in both the music business, but also a D programmer for many years, I got to say this was the most inspirational quote I have ever read and it'll be my inspiration in both fields.
For someone who is in both the music business, but also a D programmer for many years, I got to say this was the most inspirational quote I have ever read and it'll be my inspiration in both fields.
> D's niche
That represents a misunderstanding of D. Unlike Go and Rust, which were built for one specific use case (Go for the work done at Google, and Rust for writing a browser), D is an all-around good general purpose programming language. If it did have a niche, it would be as a C replacement, and it is the best available tool for that.
Your comment also implies that D is not used. Download statistics, forum activity, and the existence of users suggests otherwise.
That represents a misunderstanding of D. Unlike Go and Rust, which were built for one specific use case (Go for the work done at Google, and Rust for writing a browser), D is an all-around good general purpose programming language. If it did have a niche, it would be as a C replacement, and it is the best available tool for that.
Your comment also implies that D is not used. Download statistics, forum activity, and the existence of users suggests otherwise.
Rust was built to be good for browsers, but also as a general purpose language. We’ve made decisions in the past to not include things the Servo folks wanted, for example.
I'm a little confused. I've heard of Digital Mars around the internet but I don't know what it is or why the company was started.
For my entire life as a Software Engineer the idea of a close sourced or proprietary compiler was just alien to me.
What set you down the path of writing compilers? Did anyone buy licenses to your compilers? Why was D started?
A more technical question: Was there any abstraction/pattern that has been deeply rooted into your code base that you are unable to change due to prevalence yet this pattern/abstraction makes it more difficult to maintain your code base? In any other words: have there been any mistakes made?
For my entire life as a Software Engineer the idea of a close sourced or proprietary compiler was just alien to me.
What set you down the path of writing compilers? Did anyone buy licenses to your compilers? Why was D started?
A more technical question: Was there any abstraction/pattern that has been deeply rooted into your code base that you are unable to change due to prevalence yet this pattern/abstraction makes it more difficult to maintain your code base? In any other words: have there been any mistakes made?
digitalmars.com !
When I started, everything was closed source. Open source was inconceivable.
I started writing compilers in order to speed up my game Empire (www.classicempire.com). Compilers turned out to be more interesting :-)
Yes, many bought licenses.
D was started because I got bored with retirement (6 weeks of watching TV will do that do you). My ideas for improving C++ met with enormous resistance. So I did my own language. Ironically, D features have steadily been adopted by C++.
> have there been any mistakes made?
Haha, I could spend months responding to that!
Probably the worst abstraction in the DMC code base is the use of linked lists. They're slow, cache-unfriendly, and leaky. I learned my lesson with DMD, which uses adjustable arrays instead.
I've tried encapsulating the lists, like CodeBuilder in the back end, but it's a LOT of work to get that in. It wouldn't have been so much work if the list abstraction didn't leak the structure of the list at every opportunity.
When I started, everything was closed source. Open source was inconceivable.
I started writing compilers in order to speed up my game Empire (www.classicempire.com). Compilers turned out to be more interesting :-)
Yes, many bought licenses.
D was started because I got bored with retirement (6 weeks of watching TV will do that do you). My ideas for improving C++ met with enormous resistance. So I did my own language. Ironically, D features have steadily been adopted by C++.
> have there been any mistakes made?
Haha, I could spend months responding to that!
Probably the worst abstraction in the DMC code base is the use of linked lists. They're slow, cache-unfriendly, and leaky. I learned my lesson with DMD, which uses adjustable arrays instead.
I've tried encapsulating the lists, like CodeBuilder in the back end, but it's a LOT of work to get that in. It wouldn't have been so much work if the list abstraction didn't leak the structure of the list at every opportunity.
> I started writing compilers in order to speed up my game Empire (www.classicempire.com). Compilers turned out to be more interesting :-)
That seems to be a recurring pattern in the history of software. Unix was created for similar reasons (to create a self-hosted development environment for game), and the Linux kernel started out as a terminal emulator.
That seems to be a recurring pattern in the history of software. Unix was created for similar reasons (to create a self-hosted development environment for game), and the Linux kernel started out as a terminal emulator.
> D was started because I got bored with retirement (6 weeks of watching TV will do that do you).
Waw, you retired "young".
Waw, you retired "young".
Thank you for Empire, Walter! One of the best turn-based strategy computer games ever created. Many hours of fun.
> One of the best turn-based strategy computer games ever created.
Who'd have thought that would ever happen? I wrote it simply because it was the game I wanted to play.
Who'd have thought that would ever happen? I wrote it simply because it was the game I wanted to play.
I just want to thank you for all your work on this. DMC is the very first C compiler I ever used, back in the early/mid 2000s. It was my first real foray into programming, and I was running Windows XP. I remember liking that DMC was free and no-BS. Unlike some of the competition (at least as far as 11-year-old me understood), it didn’t want me to install a whole IDE or other craziness along with it. Good to see that the project is still going.
Thanks for the kind words! I'm auld skool in that I like command line tools, and DMC++ reflects that in not requiring an IDE. The actual compiler and libraries are pretty small.
Back in the aulden days, it could also be run directly from the distribution CD without requiring an install. These days the "install" is merely unzipping the file.
Back in the aulden days, it could also be run directly from the distribution CD without requiring an install. These days the "install" is merely unzipping the file.
Same here! 11 year old me got Turbo C++ as a birthday gift. Once I learned the language, I was frustrated at how Microsoft and Borland and everyone tried to lock you into their ecosystem. MinGW was an option but Digital Mars was the bee's knees. A big stepping stone to my eventual career.
Nice! I didn't get any access to a computer till I was 16. I had to punch cards and hand them to the teacher who'd run them as batch jobs. In college all students had accounts on the college PDP-10, a marvelous machine for its day.
Dear Walter,
Thank you for the great work you are doing.
If you could get people to include D in the benchmarks / shootouts that get published it would help improve the popularity of D.
FYI - Thatneedle.com already uses it for part of the backend data processing workflow.
Thank you for the great work you are doing.
If you could get people to include D in the benchmarks / shootouts that get published it would help improve the popularity of D.
FYI - Thatneedle.com already uses it for part of the backend data processing workflow.
Isaac Gouy is the gatekeeper for the shootout, and he refuses to include D for reasons he's refused to elucidate.
I stopped publishing benchmarks myself 15 years ago as people always assumed my thumb was on the scale.
I stopped publishing benchmarks myself 15 years ago as people always assumed my thumb was on the scale.
>> for reasons he's refused to elucidate
For the simplest reasons that I have stated to you many times!
Including every language implementation that the language author would like to have included is more work than I am willing to do, period.
Sept 13 2008: 63 language implementations were shown-
https://web.archive.org/web/20080913030117/http://shootout.a...
- currently, 27 language implementations are shown.
You could truthfully say "he refuses to include [at-least 30 language implementations]". In that regard, there's nothing special about D.
For the simplest reasons that I have stated to you many times!
Including every language implementation that the language author would like to have included is more work than I am willing to do, period.
Sept 13 2008: 63 language implementations were shown-
https://web.archive.org/web/20080913030117/http://shootout.a...
- currently, 27 language implementations are shown.
You could truthfully say "he refuses to include [at-least 30 language implementations]". In that regard, there's nothing special about D.
I have no context regarding the history of the benchmarks game. With that in mind, I have a question:
What about you create a technical specification (including both technical depth and common-sense breadth) for what kind of benchmark you'll accept, throw the whole thing on GitHub, and then refuse 99% of pull requests? :) (ie, only accept really really good quality benchmark implementations)
Eventually, enough developers unimpressed that Language X is not adequately represented would step up to the plate and maintain good-quality benchmark code. (This could get pretty interesting with rapidly-evolving languages like Rust.)
Obviously this is all very ideal and I can see so many ways such an endeavor could go horribly wrong, sure. I can also very easily see you having floated such an idea then discarded it for reasons I haven't even thought of.
What about you create a technical specification (including both technical depth and common-sense breadth) for what kind of benchmark you'll accept, throw the whole thing on GitHub, and then refuse 99% of pull requests? :) (ie, only accept really really good quality benchmark implementations)
Eventually, enough developers unimpressed that Language X is not adequately represented would step up to the plate and maintain good-quality benchmark code. (This could get pretty interesting with rapidly-evolving languages like Rust.)
Obviously this is all very ideal and I can see so many ways such an endeavor could go horribly wrong, sure. I can also very easily see you having floated such an idea then discarded it for reasons I haven't even thought of.
What about I work to publish crowd-sourced programs and measurement scripts: so that anyone can make their own comparisons, on their own hardware, against whatever other language implementations they want to write programs for :-)
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Ah; that certainly works too!
The only thing I wonder about is allowing any given set of hardware to be compared with another set of hardware with anything approaching accuracy.
What would be awesome is if someone could figure out whether they'd need Raspberry Pi Zero to run some algorithm or if they could get away with just using a BBC Micro:Bit, by looking at a benchmark run submitted to the site from an i9-7940X.
Sadly I suspect the amount of realtime introspection needed (memory speed, practical cache coherency (per level), bus saturation, instructions used per cycle) would make this difficult - particularly because, even if a given benchmark was going to go fishing for performance counter info (and I just learned that even the Gen1's ARM 1176-based PMU provides a few, including one that counts instructions), benchmarking memory I/O is a bit harder; PCI DMA MMIO debug cards only map a small range of memory, like 256k or so, and I don't know if such cards can back the region with actual RAM. I suspect the access latency would be so different than from normal RAM that even if this did exist it'd never be used. Sigh.
And then differences in compiler optimization approach would have to be taken into account, and thorough understanding of assembly language for all target architecture(s) would be needed to have the time of day to page through the diff analysis...
Hmm, I think "simple" got left behind a few thousand miles ago. It's kinda (morbidly?) fascinating how different that different architectures are on the ground, hah.
The only thing I wonder about is allowing any given set of hardware to be compared with another set of hardware with anything approaching accuracy.
What would be awesome is if someone could figure out whether they'd need Raspberry Pi Zero to run some algorithm or if they could get away with just using a BBC Micro:Bit, by looking at a benchmark run submitted to the site from an i9-7940X.
Sadly I suspect the amount of realtime introspection needed (memory speed, practical cache coherency (per level), bus saturation, instructions used per cycle) would make this difficult - particularly because, even if a given benchmark was going to go fishing for performance counter info (and I just learned that even the Gen1's ARM 1176-based PMU provides a few, including one that counts instructions), benchmarking memory I/O is a bit harder; PCI DMA MMIO debug cards only map a small range of memory, like 256k or so, and I don't know if such cards can back the region with actual RAM. I suspect the access latency would be so different than from normal RAM that even if this did exist it'd never be used. Sigh.
And then differences in compiler optimization approach would have to be taken into account, and thorough understanding of assembly language for all target architecture(s) would be needed to have the time of day to page through the diff analysis...
Hmm, I think "simple" got left behind a few thousand miles ago. It's kinda (morbidly?) fascinating how different that different architectures are on the ground, hah.
Oops:
- To clarify, I meant the Gen1 Raspi.
- I now realize (after having actually had a proper look) that while the Micro:Bit does use "JavaScript" and "Python", they're different, microcontroller-specific implementations, and I should have used a different example there, like an Intel NUC or perhaps an ODROID board or similar.
- To clarify, I meant the Gen1 Raspi.
- I now realize (after having actually had a proper look) that while the Micro:Bit does use "JavaScript" and "Python", they're different, microcontroller-specific implementations, and I should have used a different example there, like an Intel NUC or perhaps an ODROID board or similar.
>> The only thing I wonder about is allowing any given set of hardware to be compared with another set of hardware with anything approaching accuracy.
Just systematically enough to be reminded that a different context may have different relative performance.
Just systematically enough to be reminded that a different context may have different relative performance.
You've never explained what your criteria is. Just that you didn't want to include D.
I always did want to include D — which is why we did include D — of course, we also used to include Scala and Clojure and…
[deleted]
I know you're publicly directly messaging, but as an outsider to the discussion, I don't see any actual mention in your posts why D isn't included. Just that it "used to be."
There are many of benchmark projects that include D and don't appear to be struggling under any kind of massive burden. For example:
https://github.com/kostya/benchmarks
What are your actual reasons for not keeping D... "scala... and Clojure and ..."? The results in the previous link show D as a massive competitor (sometimes 1st place beating C and C++) on both memory and speed. Wouldn't the purpose of benchmarks be... to highlight useful, highly-scoring languages? Isn't that one of the primary reasons people read benchmarks?
(The D implementations are also often smaller in lines of code, as per this benchmark project:
https://togototo.wordpress.com/2013/08/23/benchmarks-round-t...
)
There are many of benchmark projects that include D and don't appear to be struggling under any kind of massive burden. For example:
https://github.com/kostya/benchmarks
What are your actual reasons for not keeping D... "scala... and Clojure and ..."? The results in the previous link show D as a massive competitor (sometimes 1st place beating C and C++) on both memory and speed. Wouldn't the purpose of benchmarks be... to highlight useful, highly-scoring languages? Isn't that one of the primary reasons people read benchmarks?
(The D implementations are also often smaller in lines of code, as per this benchmark project:
https://togototo.wordpress.com/2013/08/23/benchmarks-round-t...
)
>> I don't see any actual mention in your posts why D isn't included.
Do you see any mention at kostya/benchmarks of why ".NET Core" or Ada isn't included?
>> … benchmark projects that include D and don't appear to be struggling under any kind of massive burden.
Check when those kostya/benchmarks language implementation versions were released.
>> What are your actual reasons for not keeping…
I don't want to do the work.
Do you see any mention at kostya/benchmarks of why ".NET Core" or Ada isn't included?
>> … benchmark projects that include D and don't appear to be struggling under any kind of massive burden.
Check when those kostya/benchmarks language implementation versions were released.
>> What are your actual reasons for not keeping…
I don't want to do the work.
I was a bit surprised by the inclusion of lesser languages and the omission of D !!
Please share the secret of your tenacity and inspiration in the face of such "setbacks". How do you do it on a day to day basis?
Please share the secret of your tenacity and inspiration in the face of such "setbacks". How do you do it on a day to day basis?
I know how good D is and I have a lot of confidence in it. There are a lot of great people using it that are getting their jobs done faster & better and are thereby making more money. That's what matters to me.
Everybody likes to make more money :-)
Back when I was a brand new engineer at Boeing, I was talking to my lead engineer about the beauty of aerospace engineering. He smiled and said I didn't get it. Boeing wasn't making airplanes, they were building money making machines for airline companies. That the airplane turned out to be a beauty was just a happy side effect!
D isn't about my personal aggrandizement. It's about how effective it is for users at solving their problems and making money for them.
Everybody likes to make more money :-)
Back when I was a brand new engineer at Boeing, I was talking to my lead engineer about the beauty of aerospace engineering. He smiled and said I didn't get it. Boeing wasn't making airplanes, they were building money making machines for airline companies. That the airplane turned out to be a beauty was just a happy side effect!
D isn't about my personal aggrandizement. It's about how effective it is for users at solving their problems and making money for them.
Has there been any recent discussion on this? I suspect earlier reasons might have included D not being packaged for Debian?
It can be though to shake "early license impressions" - D (dmd specifically) is one example, Ada (FSF GNAT vs AdaCore's GNAT Pro and Ada-gnat - GPL w/o runtime exception) is another.
[ed: if others are interested in "make your own measurements and host it yourself", relevant page with link to code etc appear to be:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
]
It can be though to shake "early license impressions" - D (dmd specifically) is one example, Ada (FSF GNAT vs AdaCore's GNAT Pro and Ada-gnat - GPL w/o runtime exception) is another.
[ed: if others are interested in "make your own measurements and host it yourself", relevant page with link to code etc appear to be:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
]
> any recent discussion
Not since I asked him to stop dropping by the D forum to remind us that he wouldn't include D in the shootout.
I've personally lost all interest in it.
(The benchmarks are also small and too easily gamed by the author of the benchmark code, and the compiler developer. I encourage people to run timing tests on their own code, as that is what matters to them.)
Not since I asked him to stop dropping by the D forum to remind us that he wouldn't include D in the shootout.
I've personally lost all interest in it.
(The benchmarks are also small and too easily gamed by the author of the benchmark code, and the compiler developer. I encourage people to run timing tests on their own code, as that is what matters to them.)
My experience has been that I get better ideas of benchmarks by profiling my real application code, porting the hotspots to the new language or framework within a mostly bare skeleton and testing it. It’s not perfect, but gives me a better idea as to whether moving will actually help!
> I encourage people to run timing tests on their own code, as that is what matters to them.
This is the heart of the matter: benchmarking toy and unrelated bits of code amount to the same thing.
I think what people really need is a straightforward, accessible understanding of where a software implementation is inefficient. Design inefficiency can sometimes be "hacked over" (read "paved over") a bit like evening out technical debt; implementation inefficiencies, perhaps not so much. Making a complex database query faster by fiddling with (very) obscure SQL options because a given vendor's query planner is broken in a rare edge-case is one example that comes to mind.
I think it's especially sad when a software implementation becomes renowned for its inefficiency. It kinda takes the heat off in what I would argue is a very unfair way, like it legitimizes slowness like speed isn't a worthy pursuit... and then we wonder why our computers are slow. (Yeah, I'm thinking about Python here... and to a small extent many interpreted languages.)
In the context of D (and now DMC++ :D), so specifically compilers, it would be interesting to know what areas of the language don't generate especially fast code, or what bits might produce code that uses a little memory than it could, etc. Because that's what people really want to know before they take the time to write/port; and if they know about all the instances of "don't do XYZ in this very specific way" ahead of time, maybe they can write the best possible code on the first try! (Design and implementation are intertwined in practice.)
I suspect the list of such "avoid"s may not be long. It might make for a particularly efficient kind of developer user manual.
This is the heart of the matter: benchmarking toy and unrelated bits of code amount to the same thing.
I think what people really need is a straightforward, accessible understanding of where a software implementation is inefficient. Design inefficiency can sometimes be "hacked over" (read "paved over") a bit like evening out technical debt; implementation inefficiencies, perhaps not so much. Making a complex database query faster by fiddling with (very) obscure SQL options because a given vendor's query planner is broken in a rare edge-case is one example that comes to mind.
I think it's especially sad when a software implementation becomes renowned for its inefficiency. It kinda takes the heat off in what I would argue is a very unfair way, like it legitimizes slowness like speed isn't a worthy pursuit... and then we wonder why our computers are slow. (Yeah, I'm thinking about Python here... and to a small extent many interpreted languages.)
In the context of D (and now DMC++ :D), so specifically compilers, it would be interesting to know what areas of the language don't generate especially fast code, or what bits might produce code that uses a little memory than it could, etc. Because that's what people really want to know before they take the time to write/port; and if they know about all the instances of "don't do XYZ in this very specific way" ahead of time, maybe they can write the best possible code on the first try! (Design and implementation are intertwined in practice.)
I suspect the list of such "avoid"s may not be long. It might make for a particularly efficient kind of developer user manual.
I don't really see a big problem with a little bit of gaming on the benchmark-code side; with a few implementations to compare, it might even give some hints for idiomatic efficient code.
Gaming from the compiler/runtime side would be uglier - but I guess it is somewhat mitigated by real languages running the "general release" version.
No harm in "fastest way to list first 1000 prime numbers" being "print static list of first 1000 prime numbers".
Hand there's some value in having a standard benchmark harness that works easily across languages - as a helpful tool with "running your own benchmarks". Assuming the harness is any good, that is.
Gaming from the compiler/runtime side would be uglier - but I guess it is somewhat mitigated by real languages running the "general release" version.
No harm in "fastest way to list first 1000 prime numbers" being "print static list of first 1000 prime numbers".
Hand there's some value in having a standard benchmark harness that works easily across languages - as a helpful tool with "running your own benchmarks". Assuming the harness is any good, that is.
> I don't really see a big problem with a little bit of gaming on the benchmark-code side
I just got tired of the vitriol leveled at me with no basis. Things like I must have "sabotaged" other compilers. Probably the absolute worst one was when the journalist decided that Datalight Optimum C ran the benchmarks so fast, it must be a compiler bug and removed the benchmark results from his compiler roundup, calling DC a buggy compiler.
The reality was Datalight C was the first C compiler on DOS to do data flow analysis, and it deleted dead code. (Benchmarks of that era did nothing useful, and dfa detected that.) No cheating at all. A couple years later, everyone did dfa.
I just got tired of the vitriol leveled at me with no basis. Things like I must have "sabotaged" other compilers. Probably the absolute worst one was when the journalist decided that Datalight Optimum C ran the benchmarks so fast, it must be a compiler bug and removed the benchmark results from his compiler roundup, calling DC a buggy compiler.
The reality was Datalight C was the first C compiler on DOS to do data flow analysis, and it deleted dead code. (Benchmarks of that era did nothing useful, and dfa detected that.) No cheating at all. A couple years later, everyone did dfa.
I did run my own prime number crunching benchmark for fun and D blew Rust away but lagged behind Go. I used mutable Vec and HashSet in Rust, associative arrays and arrays in D, maps and arrays in Go to store the sieves.
You see, that's the point - even if you do something as simple, there are many ways to do it (and different compiler versions, especially in the case of D), different optimizations at the code and compiler level and all that - it's practically impossible to have a reliable, comprehensive benchmark.
(That said, D is lightning fast for me!)
(That said, D is lightning fast for me!)
HashSet uses a cryptographically secure hashing algorithm by default, it’s gonna be slow.
What's the Rust equivalent of Go maps or D associative arrays then?
The Rust HashMap and HashSet implementations are generic over hasher: you can pick a faster one if you don't have to worry about getting ddos'd. Last I checked, the go-to fast hasher was fnv: https://doc.servo.org/fnv/
How often do I need to explain that this siphash claim of DDOS protection is utter nonsense. siphash can easily be brute forced like every insecure hash function (<256 bits), and proper DDOS protection can only be provided by a proper collision strategy. Even DJB himself does so.
Well, it's not in the standard lib and I couldn't get my program to compile. Compare that to D or Go, where you don't have to fight the copiler.
Rust has a different take on the standard library than many other languages. It's kept quite minimal, because it's trivial to use a package.
Is there any way to use it directly in the source w/o having to create a Crate.toml and src dirs? Is there a getting started document? Dub recently included such a feature.
Yup, this is 100% correct.
>> Has there been any recent discussion on this?
https://forum.dlang.org/search?q=benchmarks+game&scope=forum
https://forum.dlang.org/search?q=benchmarksgame&scope=forum
https://forum.dlang.org/search?q=benchmarks+game&scope=forum
https://forum.dlang.org/search?q=benchmarksgame&scope=forum
Not sure why you're getting down voted was about to post something along the same lines (though admittedly linking to a couple of threads, not just the search). But I don't think everyone on hn would be aware of the d forums (nor that it's a rather magnificent piece of "groupware" with usenet and irc support on top of (or should I say beneath) a quick Web interface.
https://github.com/CyberShadow/DFeed
https://github.com/CyberShadow/DFeed
From my perspective, the relevant "couple of threads" would be the old discussions which showed various people in the D community actually had the measurement scripts working with D programs: and yet that work becomes abandoned, so there's nothing like —
https://github.com/kostya/crystal-benchmarks-game
https://github.com/kostya/crystal-benchmarks-game
Thank you for the AMA. :)
What is your opinion of Rust?
It seems to me like Rust and D have the same target audience and both want to be the next C++.
What is your opinion of Rust?
It seems to me like Rust and D have the same target audience and both want to be the next C++.
Rust and D are very different languages. I suspect the choice between the two is more a matter of personal taste.
D, for example, achieves memory safety in a very different way than D's borrow checker.
D, for example, achieves memory safety in a very different way than D's borrow checker.
Has the re-write to D felt productive?
May it have been better to start from scratch?
Was the "D as a better C" approach inspired by your want to transition DMC to D?
Was the "D as a better C" approach inspired by your want to transition DMC to D?
> Has the re-write to D felt productive?
Yes, it's been oddly satisfying.
> May it have been better to start from scratch?
Ah, the age old question. I can guarantee, though, the answer is no. It took me maybe a couple weeks to convert the entire front end from C++ to D. Contrast that with the Warp preprocessor I wrote for Facebook, which took many months, and I knew what I was doing. And that is just the preprocessor!
Basically, writing a C++ front end takes 10 man years. I know of no effort that took less time, and this is assuming the best in the business doing the writing.
> Was the "D as a better C" approach inspired by your want to transition DMC to D?
Partially, yes. And certainly doing the transition work has improved betterC. Nothing like proving it works than translating a crotchety old horrifyingly complex piece of code written in 1980's style.
I plan on doing this to all my old projects that are still in use.
Yes, it's been oddly satisfying.
> May it have been better to start from scratch?
Ah, the age old question. I can guarantee, though, the answer is no. It took me maybe a couple weeks to convert the entire front end from C++ to D. Contrast that with the Warp preprocessor I wrote for Facebook, which took many months, and I knew what I was doing. And that is just the preprocessor!
Basically, writing a C++ front end takes 10 man years. I know of no effort that took less time, and this is assuming the best in the business doing the writing.
> Was the "D as a better C" approach inspired by your want to transition DMC to D?
Partially, yes. And certainly doing the transition work has improved betterC. Nothing like proving it works than translating a crotchety old horrifyingly complex piece of code written in 1980's style.
I plan on doing this to all my old projects that are still in use.
> Basically, writing a C++ front end takes 10 man years.
This is insane. No language needs to be that complex. I guess that's the power of backward compatibility: forcing an entire industry to dig itself into an ever growing hole, because in the short term we move faster by digging than by first clawing our way out.
This is insane. No language needs to be that complex. I guess that's the power of backward compatibility: forcing an entire industry to dig itself into an ever growing hole, because in the short term we move faster by digging than by first clawing our way out.
Mastering C++ takes about 10 years, too :-)
(Yes, you can be productive in C++ in much less time.)
(Yes, you can be productive in C++ in much less time.)
I haven’t yet tried D, but it’s on my list. It’s truly impressive to have a C/C++ contender which can actually compare in performance.
It’s a less serious question to ask, but was the name in any way related to Run-DMC, the 80s hip hop group?
It’s a less serious question to ask, but was the name in any way related to Run-DMC, the 80s hip hop group?
I briefly dipped into D about two years ago. In terms of features, it is similarly big as C++, but a lot more sanity-oriented in terms syntax and semantics. The library ecosystem could be better, but IIRC, it is possible to use C (maybe even C++) libraries from D.
The community is awesome, super friendly and super helpful even in the face of the most stupid newbie-questions I could come up with. ;-)
In the end, I backed out, because the language was too big and complex for my taste and needs. But if you kind-of-like C++, you are likely to fall in love with D.
The community is awesome, super friendly and super helpful even in the face of the most stupid newbie-questions I could come up with. ;-)
In the end, I backed out, because the language was too big and complex for my taste and needs. But if you kind-of-like C++, you are likely to fall in love with D.
D is indeed a fully equipped machine shop, but nobody says you have to start with the Bridgeport milling machine. You can write very capable programs with just the C-ish subset.
I tried, I really did, but then I got distracted by all those shiny features and was unable to resist the temptation to play with them all. :-) I had the same problem with C++.
I will probably give it another try one day, if only for the super-friendly and welcoming community.
I will probably give it another try one day, if only for the super-friendly and welcoming community.
No - the comparison never occurred to me.
Hopefully you see this
This is a question I'm sure many have: how feasible would it be to get DMC++ emitting Linux code?
D uses the same backend, in theory, but I'm not sure how much divergence there is between the D backend and this code.
Perhaps you could get Hello World to build, make a gigantic list of everything that's broken, and see how much traction (hopefully) appears out of thin air :)
I love tcc for its "oh it already finished" compilation time (300ms :D), even (and especially) on older hardware. I wish there was something out there to compare it with; it's quite unfortunate it sits on its own, because it hasn't had an official release in in 4 or so years.
This is a question I'm sure many have: how feasible would it be to get DMC++ emitting Linux code?
D uses the same backend, in theory, but I'm not sure how much divergence there is between the D backend and this code.
Perhaps you could get Hello World to build, make a gigantic list of everything that's broken, and see how much traction (hopefully) appears out of thin air :)
I love tcc for its "oh it already finished" compilation time (300ms :D), even (and especially) on older hardware. I wish there was something out there to compare it with; it's quite unfortunate it sits on its own, because it hasn't had an official release in in 4 or so years.
You're right, the pieces are in place to do it. I've just never taken that last step.
Oh, all right!! Cool! I'll definitely be keeping a slightly closer eye on DMC++ now and watching it for changes then, I think :)
I've wanted to play with C++ for quite some time, but (as crazy as it might sound) gcc/clang's multi-second compile times for the smallest of things (eg, messing around with FLTK, which doesn't go that crazy with C++ features) makes tinkering a bit distracting. Multiple seconds for medium+ things, maybe, but tcc has spoilt me when it comes to rapid iteration, heh.
A C++ compiler for Linux with speed reminiscent of (or maybe even similar to!) tcc would have a very big (if quiet) impact for a few people, I reckon. Something nice to have one day.
(Unrelated, but fiddling around to get `dmd -c' + external libphobos.so + ld.lld makes for especially nice compilation speed :) )
Is there any specific reason the last step you speak of hasn't been taken? Just time/inertia, or reluctance for technical reasons? I think many people would be interested to hear what effort you'd want to fold into a Linux release, if there are any technical issues.
I've wanted to play with C++ for quite some time, but (as crazy as it might sound) gcc/clang's multi-second compile times for the smallest of things (eg, messing around with FLTK, which doesn't go that crazy with C++ features) makes tinkering a bit distracting. Multiple seconds for medium+ things, maybe, but tcc has spoilt me when it comes to rapid iteration, heh.
A C++ compiler for Linux with speed reminiscent of (or maybe even similar to!) tcc would have a very big (if quiet) impact for a few people, I reckon. Something nice to have one day.
(Unrelated, but fiddling around to get `dmd -c' + external libphobos.so + ld.lld makes for especially nice compilation speed :) )
Is there any specific reason the last step you speak of hasn't been taken? Just time/inertia, or reluctance for technical reasons? I think many people would be interested to hear what effort you'd want to fold into a Linux release, if there are any technical issues.
Hi Walter, great work as always.
I'm a fan of D as a language, but how do you respond to the question of "We should just go with C# or C++, why go with a middle-ground language like D that few programmers know?"
Given that D --> C++ migrations have happened in the past, this strikes me as D's big challenge: finding its place.
I'm thinking in particular of OpenMW: https://forum.openmw.org/viewtopic.php?t=2189
I'm a fan of D as a language, but how do you respond to the question of "We should just go with C# or C++, why go with a middle-ground language like D that few programmers know?"
Given that D --> C++ migrations have happened in the past, this strikes me as D's big challenge: finding its place.
I'm thinking in particular of OpenMW: https://forum.openmw.org/viewtopic.php?t=2189
I ask them how much money they've lost on C/C++ buffer overflows in the past, and how much they're willing to lose on them in the future :-)
Heartbleed. A C buffer overflow bug so disastrously expensive it has it's own logo!
(I know C# doesn't have buffer overflows either, but C# is a much bigger change than going to D, and is less portable.)
Heartbleed. A C buffer overflow bug so disastrously expensive it has it's own logo!
(I know C# doesn't have buffer overflows either, but C# is a much bigger change than going to D, and is less portable.)
Valid point, buffer-overflows can be disastrous and should be easily preventable, or impossible, in a sensible language.
For OpenMW though, it's not a concern. They're building a single-player video game; the input is always trusted. As far as I can see, they made the right call by moving to C++.
Again, I really like the D language - but I can see why a project manager would go with C++.
For OpenMW though, it's not a concern. They're building a single-player video game; the input is always trusted. As far as I can see, they made the right call by moving to C++.
Again, I really like the D language - but I can see why a project manager would go with C++.
TBF, c++ has std::vector and std::list.
And with the "usual" access '[]' std::vector doesn't bound check either, you have to use 'at' for this (except in some library with some flags ), doesn't seem that safe to me!
Agree. It strikes me as silly that C++ doesn't provide something like a `CHECKED` macro, so that operator[] could always be range-checked in debug/dev builds, but not in release builds. The two-different-methods approach seems awfully clunky - what ends up happening is that no-one uses the `at` method. I see no good reason not to enable range-checks by default in debug builds.
This 'unsafe by default' philosophy isn't universal in C++ though. The smart-pointer class-templates are always thread-safe, despite the possible performance consequences.
This 'unsafe by default' philosophy isn't universal in C++ though. The smart-pointer class-templates are always thread-safe, despite the possible performance consequences.
What's the business model / long term plan for sustaining development on the compiler / D?
Not OP, but https://digitalmars.com/consulting.html has sat around for a while. I get the (un-citeable) impression it has a few takers (simply by virtue of the fact that the link exists, more or less).
There is also https://dlang.org/foundation/about.html which has links to a donations page which has around 3k USD a year of income.
I was just looking at your classicempire site and stumbled upon the rejection letters!!
Did you take up Sirius's offer to act as broker for 30% cut on deal?
Did you take up Sirius's offer to act as broker for 30% cut on deal?
No. 30% is absurdly high.
Could you enlighten on how you managed to take those to market after the rejections?
Interstel didn't reject it, and Interstel Empire made history!
Did the rewrite give you any interesting perspectives on how to structure BetterC differently to both C and D?
More like it just made clear some shortcomings that needed to be fixed.
Is the exception handling DMC C++ implements zero cost or setjmp/longjmp based?
C++ EH is never zero cost, despite the hype. Herb Sutter just wrote a proposal to redo the semantics in C++ to reduce the cost of it.
DMC++'s EH is not setjmp/longjmp, it is Windows SEH (Structured Exception Handling) based. The 32 bit DOS extender EH is based on my own table-based design.
DMC++'s EH is not setjmp/longjmp, it is Windows SEH (Structured Exception Handling) based. The 32 bit DOS extender EH is based on my own table-based design.
I'm pretty clueless here, but from a quick search on GitHub it looks like there's support for NT exception handling, and DWARF exception handling. (I realise this doesn't really answer your question, but it's a start.)
https://github.com/DigitalMars/Compiler/blob/7a33233c/dm/src... https://github.com/DigitalMars/Compiler/blob/7a33233c/dm/src...
https://github.com/DigitalMars/Compiler/blob/7a33233c/dm/src... https://github.com/DigitalMars/Compiler/blob/7a33233c/dm/src...
Are you adding any features to the C/C++ compiler or just migrating to D?
Never mix migrating with adding features. It's the path to the dahhk side!
Yours was the compiler I used to learn C++ in 2003. Thank you!
Having nice users like you guys is very gratifying!
I learned C++ in 1989 using one of his earlier compilers!
I still have somewhere Walter's Zortech C++ that was life saver for me at one point.
H/W: i386 machine 25 mhz, 2mb RAM. Internet: No OS: MSDOS IDE: MultiEditor + Zortech C++ Where: in the middle of nowhere - small town between Europe and Asia.
At some point upgraded the whole setup to Symantec C++ on Windows - for unknown now reasons.
H/W: i386 machine 25 mhz, 2mb RAM. Internet: No OS: MSDOS IDE: MultiEditor + Zortech C++ Where: in the middle of nowhere - small town between Europe and Asia.
At some point upgraded the whole setup to Symantec C++ on Windows - for unknown now reasons.
For me also Zortech was gold. The Symantec version was also fine.
Loved the compiler and the UI. Best UI ever. Esp. if compared to the Turbo/Borland stuff and then MSVC.
Loved the compiler and the UI. Best UI ever. Esp. if compared to the Turbo/Borland stuff and then MSVC.
[deleted]
Hasn't had a release since 2013, but the Github code is still getting updates as recently as the last few weeks. It appears to be written in a mix of itself and D. Wasn't clear to me how you would go about bootstrapping it.
Download DMC and DMD, and you should be good to go.
I was scratching my head how I never heard of DMC++ until I realized that this is related to Zortech C++ compiler I've used (and loved) while ago.
[deleted]
I have been asking for them to fix the license on Open Watcom for a while now. A C compiler that has full support for x86 segmentation would be very useful for some projects.
You've got that with DMC today.
Why should I favor this compiler instead of gcc or clang?
On Windows, DMC++ being developed on Windows tends to just work better on Windows. My experience in general with Linux tools ported to Windows is the adaptation to the Windows file system conventions is incomplete.
It was the first 3rd party compiler for Windows (1.0)
It's apparently really nice to use (I'm on Linux :( )
It was written by one person
It targets DOS, Windows and OS/2 (mostly Win32)
It's apparently really nice to use (I'm on Linux :( )
It was written by one person
It targets DOS, Windows and OS/2 (mostly Win32)
For a while it was the only C++ compiler for Windows. (I had figured out how to do all the various weird stack frame variations Windows required.) We sold a lot of those :-)
Interesting to know.
What’s the use case for this compared to gcc or clang?
What C and C++ standard versions does this support?
There doesn't appear to have been an official release of the compiler since 8.57, announced on August 8, 2013.
https://forum.dlang.org/group/c++.announce
I can't find anything about what changed between 8.52 and 8.57. But in 8.52, there wasn't even support for C++03, which the DMC site self-reports:
https://digitalmars.com/ctg/CPP0x-Language-Implementation.ht...
cppreference maintains a compiler support grid for features in the C++11 and later standards, which includes DMC 8.52 and mentions a small number of supported features.
http://en.cppreference.com/w/cpp/compiler_support
Here's a post on the DMC forum from 2015 which seems to agree that C++11 support is generally not there.
https://forum.dlang.org/thread/[email protected]...
https://forum.dlang.org/group/c++.announce
I can't find anything about what changed between 8.52 and 8.57. But in 8.52, there wasn't even support for C++03, which the DMC site self-reports:
https://digitalmars.com/ctg/CPP0x-Language-Implementation.ht...
cppreference maintains a compiler support grid for features in the C++11 and later standards, which includes DMC 8.52 and mentions a small number of supported features.
http://en.cppreference.com/w/cpp/compiler_support
Here's a post on the DMC forum from 2015 which seems to agree that C++11 support is generally not there.
https://forum.dlang.org/thread/[email protected]...
If you want to build it, you'll need to download the C++ binary from digitalmars.com, and the D compiler from dlang.org.