EDG C++ front-end goes public (edgcpp.org)

https://en.wikipedia.org/wiki/Edison_Design_Group ref 9: https://herbsutter.com/2025/11/10/trip-report-november-2025-...

Also, since i mentioned Lazarus, if it can compile itself to Free Pascal, i wonder if it'd be useful for adding C++ support to Lazarus itself so that Free Pascal and C/C++ can be mixed in a project to make self-contained executables for desktop applications. It'd most likely need much more work than that just the compilation to make it a first class citizen like Free Pascal itself is for Lazarus/LCL (e.g. things like the object inspector and code tools being able to understand C++ well enough so that refactoring and stuff like doubleclicking on a button in a form automatically declaring and defining the handler and moving the editor cursor to the newly defined handler's code body), but maybe it could be used as a starting point.

For background -- and I am not an expert here -- their C++ frontend is widely known. I first heard of it because Visual C++'s Intellisense uses it, which was notable because VC does not use the msvc frontend for its own completion. I understand it's been either used or evaluated for other frontends in the past too. I worked as PM for one C++ product, and was fortunate to be able to learn a lot from our engineers; we didn't use it, but they thought highly of EDG.

It has a very strong reputation for being correct. And as such, I think open sourcing it will be a very beneficial thing for the C++ community.

The source code itself: https://github.com/edgcpp/compiler

Documentation: https://edgcpp.org/doc/

And for those curious the license SPDX is: Apache-2.0 WITH LLVM-exception

i.e.

- https://spdx.org/licenses/Apache-2.0.html

- https://spdx.org/licenses/LLVM-exception.html

It isn't perfect, but it is awfully good.

Another interesting thing is that in 1999ish, when SGI open-sourced the Irix compiler (known as sgicc) into open-64, the it used a terribly hacked version of gcc as a front end to generate its internal intermediate representation.

This was because sgicc, even back then, used EDG as a front end, and EDG wasn't open and couldn't be opened up at the time.

The combination worked OK, but was pretty hacky, and I wonder if open64 would have gotten more traction than it did if it had been able to use EDG, or perhaps some other front end actually designed as a front end instead of the hacky thing.

EDIT: But in this case it seems something significant is being released, it would be better with less writing and more human if possible.

Looking back at that code definitely brings back memories. As a consumer of both frontends, I will say I much preferred working with Clang's. Both needed extra work on top to support everything we needed. Maybe I'm just not as acquainted with C as I would like to be. It's cool to look at this again, though.

EDG was just 3 guys back then.

Where other languages might use inheritance, EDG still uses the C-style `union { ... } variant;`.

On a related note, compiling EDG is extremely fast: on my machine, the EDG frontend compiles in <10s; whereas clang takes >10min (caution unfair comparison: clang includes much more than just a frontend).

We certainly held it in high regard. It was rare that a compiler bug was in their code rather than ours :).

"Continuity is the point. This is a change of steward, not a change of course."

JFC it's like reading the haphazard ramblings of a lunatic. It's incredibly sad that a project of this importance felt that their site was safe in the hands of the AI slop machine. The site barely makes any sense.

It looks weird, but it actually makes sense! The flow is more natural - first the function definition, and then the explanation of what it does. It also avoids repeating the function name.