https://en.wikipedia.org/wiki/Edison_Design_Group ref 9: https://herbsutter.com/2025/11/10/trip-report-november-2025-...
Yes, but no reflection on the burn out this causes for the c++ community?
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 reason why the EDG frontend is being open-sourced is because EDG itself is closing up shop, and the open sourcing is an interim solution as EDG's customers work on migrating to using Clang instead. So... it's really not good news, because it means that one of the frontends is basically reaching end-of-life.
(and I'm implicitly using C++11 here when I say "C++", given that it effectively defines 'modern' C++).
But also quite sad. They've announced that they are closing down.
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.
You can already mix Free Pascal with C/C++ code if you use the same linker and libraries - i did manage to get FLTK statically linked with an initial backend for Lazarus in fact - this shot[0] shows a form and a few buttons from a self-contained binary on Linux (it links against FLTK statically and X11/etc dynamically).
But it is a PITA to get working for C++ libraries specifically (and you need a C intermediate for FPC to use). Also i couldn't get it to work for Win32, only Linux.
[0] http://runtimeterror.com/pages/iv/images/8a6ff400ed9b0d424be...
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.
> LLVM Exceptions to the Apache 2.0 License
> As an exception, if, as a result of your compiling your source code, portions of this Software are embedded into an Object form of such source code, you may redistribute such embedded portions in such Object form without complying with the conditions of Sections 4(a), 4(b) and 4(d) of the License.
> In addition, if you combine or link compiled forms of this Software with software that is licensed under the GPLv2 ("Combined Software") and if a court of competent jurisdiction determines that the patent provision (Section 3), the indemnity provision (Section 9) or other Section of the License conflicts with the conditions of the GPLv2, you may retroactively and prospectively choose to deem waived or otherwise exclude such Section(s) of the License, but only in their entirety and only with respect to the Combined Software.
His wife Anne was one of my professors as well (Cobol). I promised her I would never get a job writing Cobol. Unbroken.
Incredibly smart people...
Imagine telling your competitors not to copy some feature you have and them listening!
One of EDG developers prototyped his idea, and brought it to WG21 when it seemed reflection as originally thought for C++17 was never happening.
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.
We have two "back ends": c_gen_be.c generates C code from the lower IL ("intermediate language"; EDG's term for the AST) and cp_gen_be.c generates C++ code from the unlowered IL.
EDIT: But in this case it seems something significant is being released, it would be better with less writing and more human if possible.
llm overused them, but llm got its training data from catchy marketing materials and youtubers
I think it's probably irrelevant in this age of Clang a) existing and b) being everywhere but it still feels like the end of an era.
I'd say: - A single executable can emulate pretty much all versions of MSVC, GCC, and Clang. (E.g., pass the option --gnu_version=80300 and it emulates GCC 8.3.0, including a large number of bugs/idiosynchrasies.) - An optimized binary is pretty small. - It builds quite quickly. (A complete "from scratch" build on a modern solid workstation will take just a few seconds.) - It has some interesting source-to-source transformation capabilities (via cp_gen_be.c). ...
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.
Steve Adamczyk, the founder, told me that he created the company to be able to enjoy his work rather than to grow it into something that would rob him of that joy (I hope I paraphrase it right): He is an awesome human!
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 :).
Something like, oh, I don't know - HTML?
"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.
So it came up in an era where folks were inventing their own style and the huge homogenizing influence of the gnu standards (and other open source projects) hadn't taken hold.
I like it. It feels like another language, and has its advantages. I really like to know of alternate ways of doing things, even if I don't adopt them myself.
void func(var1, var2) int var1, char* var2. { ... }
perhaps some legacy from that? Probably not, but just first thing that popped into my head since it feels similar :shrug:
The "frontend" is the part of the compiler that understands the input language: lexer, parser, template instantiation, constexpr evaluation, ... The EDG frontend produces an intermediate representation (IL) that is then used by the different compiler vendors to generate machine code. Or do code analysis.
EDG can also be used as a C++-to-C compiler.
Nice to see this still exists!
After all, this is how it all started back in the days of - what was it called again ? - yeah, cfront
TLDR EDG C++ is a compiler frontend developed by EDG since the 80s which has been used under the hood for a whole bunch of commercial C and C++ compilers, static analyzers, linters, and IDE code completion tools.
Odds are if you are familiar with a closed source tool in one of those categories above, there's a decent chance it uses EDG's frontend somewhere in it under the hood.