What's not mentioned in the announcement (at least based on a quick skim) is that EDG the company is winding down, which is likely the reason why they're open sourcing the front end.
Not really sad. They are getting older, worked for themselves doing presumably what they wanted their entire career, now they are done. They could have built the company up, instead it has been common knowledge for close to 10 years they were going to retire 'any day now.'
Building a company is so fraught with pitfalls, probably realized at some point that their income was good enough that they could safely work towards retiring at some point in the future without problems and drama.
> John was the most vocal person pointing out technical problems with the feature; the committee decided it did not agree and standardized the feature anyway over his and EDG’s sustained objections; and then instead of sitting back and saying “we told you so,” EDG ended up being the only company in the world who ever implemented the feature! To add a sense of proportion: It took the same team longer to implement just the C++98 export template feature than to implement a compiler front-end for the entire Java language. But John and EDG went and did it, to support the committee’s consensus decision… only to have the committee remove export template again a few years later, because John and EDG had been right about the feature’s problems. That’s a model of solid professional behavior.
Yes, but no reflection on the burn out this causes for the c++ community?
EDG has been consistently the most vocal opposers of anything that goes in the language, and in recent years had stopped keeping up. The `export` thign was an exception.
Sorry, but that's nonsense. We've supported plenty of features. We've also occasionally been the first to implement them. In recent years, we spearheaded reflection, supported, first-implemented a bunch of constant-evaluation features (consteval etc.), and supported and first-shipped C++23 "explicit this".
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.
What is not to like, job security, it is a compiled language, standard is still ongoing (there is even OOP support), one can write microservices in it, there are IDEs, and most relevant, it is still much less English to type than AI Markdown files.
There are essentially four C++ frontends: gcc, clang, MSVC, and EDG. Pretty much every C++ compiler is a reskinned version of one of those compilers. Most of the proprietary compilers have been slinking away from using EDG to using clang (e.g., Intel did this transition a few years ago).
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.
C++ is a sprawling language which will consume any available amount of effort or goodwill. So I don't expect you will see a "new life" for this codebase while continued effort on the "big three" compilers happens.
Where would that new life come from? As far as I am aware, there isn't exactly a thriving community around it which has been begging for a source release for ages, and with Clang and GCC there hasn't been a shortage of open-source C++ compilers either. And it's not exactly like the C++ ecosystem as a whole is booming, with it not having any answer to the memory safety problem.
From what I can tell this is just some retiring guys who want to make sure their life's work isn't lost to history, and who want to avoid screwing over their handful of remaining customers. Realistically, the best you can hope for is probably the occasional bugfix, and other open-source compilers scavenging it for a handful of useful clever ideas.
Maybe they're hoping the remaining customers will cooperate on keeping it up to speed? I know that f.ex. IAR are building their own backends,etc and might be an EDG customer, the MSVC IDE team aswell, now if they'll manage to get it working is another question but with the code in the open there's a chance at least.
Why not defect to clang? I'm sure some PHB's will suggest that (and that will be part of the survival, convincing those that supporting another party is a good thing).
Standardization does have it's issues, but the JS ecosystem always seems to be healthier when one implementation isn't too dominant. The question is if the C++ ecosystem is large enough to support multiple frontends.
The thing is, who's going to pull the cart? Giving stewardship to a nonprofit is perfectly fine from an IP perspective, and they'll have no trouble finding someone to herd some bugfixes, but what's going to happen when significant refactoring is needed to add support for C++26/29/etc?
Having your resident compiler expert upstream the occasional patch to keep your legacy product from dying is one thing, but which big tech company cares about this specific compiler enough to spin up an entirely new dedicated team for it? And who's going to choose a mostly-abandoned compiler front-end as a core part of a new product?
Sure, it can be done, but for each individual user defecting to clang must be looking very attractive right now.
There are fundamental differences in the design of clang and EDG at IR level that would affect whether clang can work for your use cases at all. I don't know enough in this area, so I won't say anything incorrect that would embarrass myself, but that's something you could look into.
I estimate there were very roughly 50 customers in the end. (I was an EDG engineer and didn't work on admin stuff — so it might be off, but not much. I'm estimating based on support tickets origins.) That's down from maybe double that at our max (again, my estimate). I heard of fairly few customers switching to Clang or other projects (Intel being the most notable exception). Most of our customers we "lost" were due to mergers/acquisitions (i.e., two customers suddenly became just one).
This. Maintaining a C++ front end is a lot of hard work that requires expertise -- I wouldn't be surprised if there are a bunch of CS PhDs in the team. You don't just randomly hire someone to work on compilers like with web development. I seriously doubt there will be a lot of contributions coming from the community. Maybe bug fixes, but likely not keeping up with C++ standards.
Well, if you're fine with not being up to date in terms of C++ standards there is also the OpenWatcom C/C++ compiler[0]. Jiří Malák (the main v2 dev) is doing a herculean job maintaining and improving it.
According to some older comment by jmalak, it is compatible with C++98/C++03 with some C++11 features though, yes, it isn't C++11 compatible (there are some stubs for C++11 that i can see in the code but nothing implemented).
And that's a thing though, SFINAE hinted at it but more recent versions of C++ constexpr and consteval together with relaxed constexpr and "if constexpr" and "if consteval" together with compile-time dynamic typing forced the compiler to more or less include an interpreter in the frontend.
Adding some features of C++11 isn't close to building a C++ compiler capable of 11, 14, let alone 17, 20, 23 or 26.
If you can rip out a compliant parser, it might even be better to start over on a new compiler frontend if your current compiler frontend is targeting at pre-11 level.
In my day (2006–2011) Green Hills used EDG's frontend. I have the vague impression they might have already switched away. (I know Intel ICC already switched to Clang a while ago.) I'd be very surprised to learn that GHS had ever developed their own frontend.
I'm surprised it was using EDG. My memory of green hills is that it would regularly crash on valid C++, to the point where I assumed it could only be a shitty homegrown implementation.
> I'd be very surprised to learn that GHS had ever developed their own frontend.
Actually I take that back. At the dawn of time (1982), GHS definitely had its own frontend. They switched to EDG sometime before my time. I meant I'd be surprised to learn they'd switched from EDG to something home-grown.
This also meant that in my time there was a hefty "glue" layer between the EDG frontend and the GHS middle-end (the middle-end being the tree transformations and "indep" optimizations before you got into the back-end stuff): you had to take the structures EDG produced and turn them into the structures the GHS middle-end wanted.
I was there right when John Regehr's Csmith was first making big waves. We started using it, and also rolled our own fuzzer with more focus on embedded-software trouble spots, such as `volatile` and `packed` and I forget what else. (Guy Goldstein originated and led this, as I recall.) I don't actually remember the fuzzer finding a lot of crashes, but maybe it did, and I do remember its finding a lot of miscompilations, i.e., bad optimizations.
Oracle Studio C++ and IBM XL C++ still exist, but the old front-ends are almost dead. They were both able to achieve partial C++14 support before giving up and choosing a side. Oracle chose GCC, IBM chose Clang.
I might be wrong, but I always assumed that Gimple Lint / PC Lint has its own C++23 frontend too. It looks very different from what other compilers have.
> 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.
I don't understand the second part. Can someone explain it to me?
The Apache's patent clauses conflict with the requirements of the GPL license. GPLv3 contains explicit wording to handle this conflict; GPLv2 does not. The exception here is adding wording to let this Apache-licensed code be used with GPLv2 code in the same way that it would normally be usable with GPLv3.
The EDG C/C++ front end is the primary focus of this repository. The EDG front end is known for: its excellent parsing compatibility and bug emulation, to make sure source that compiles with Clang, GCC, and MSVC compiles with EDG; extensive documentation, to assist with development and modification; and extreme configurability, to allow it to be derived for use into a large number of C/C++ oriented products.
The compiler project also includes: a C-generating back end, which can be used to generate C code for C++ programs; a C++-generating back end, which is useful for source-to-source transformation applications; a prelinker, which handles automatic template instantiation; a minimal runtime support library (but not any "real" libraries, e.g., for stream I/O); utilities to write the intermediate language to a file, read it back in, and display it in human-readable form; a name demangler; and a collection of purpose built development tools.
The C++ front end supports the ISO/IEC 14882 standard. The C++17, C++14, C++11, and C++98/03 versions of the language are fully supported. Work is under way to support the C++20 language features (see our description of language features).
Under control of command-line options, the front end also supports ANSI/ISO C (both C89 and C99, and the Embedded C TR), the Microsoft dialects of C and C++ (including C++/CLI), GNU C and C++, Clang C and C++, Sun C++, the cfront 2.1 and 3.0.n dialects of C++, and K&R/pcc C.
That last bit is out of date (we didn't work much on keeping the web site up-to-date): The front end is mostly C++23-complete (modules notably lagging), and we have several C++26 feature in as well.
The internal documentation comprises about 600 pages. The "External Interface" chapter of that document, covering command-line options, language dialect issues, and the use of language features like templates, is freely available for downloading in PDF format - https://www.edg.com/docs/edg_cpp.pdf (dated Nov 21, 2025 and hence presumably the latest version)
PS: Maybe these essential info (pointed out in my comments and updated by you) should be front and center in the new edgcpp website.
It's got history! That's really unusual for moves to open-source; the dates on the earliest commits are in 1990 and they do go forward in time so that's really unusual to have that much history. I bet there's some fun stuff in there.
If I remember correctly, EDG was the only C++ implementation that actually attempted to implement the export keyword for templates in old C++. It was this implementation experience that informed the deprecation of export. EDG is a major influence in the development of C++.
Slight correction, the other compiler/front end writers more or less read the white paper and said "that is what we thought it would be like and thus why we didn't implement it".
Imagine telling your competitors not to copy some feature you have and them listening!
Prof. John Potter told me they were the only frontend that correctly implement multiple inheritance for c++98. He thought very highly of EDG... For old time c++ folks, he was a mod on comp.lang.c++.moderated and a very cool teacher. So I hope I remember his lessons correctly...
Oh, you had him as a teacher? That's awesome.
I met him and his family 25+ years ago while they were vacationing in California... and they were all great! He was also at the Morristown WG21 meeting, where C++98 was voted out (in November 1997).
(I co-moderated comp.lang.c++.moderated with John. For several years he was the person that kept it alive.)
He was my advisor during undergrad; I had him for everything like C++, Assembly, data structures, operating systems, systems programming, an independent study, and he put me on the path to Unix guru.
His wife Anne was one of my professors as well (Cobol). I promised her I would never get a job writing Cobol. Unbroken.
One interesting thing about the EDG front end is that it can emulate all the others (and in various versions of the others) and what they support, and the errors they might detect.
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.
No, we only parse the language, do full semantic analysis, and optionally lower the representation to something that roughly matches C-language semantics. (That lowering can do some minimal inlining if needed, but that's a historical 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.
Several of our customers instrument the AST to add security-probing and/or other dynamic-analysis features.
NVCC uses it to separate out "device" constructs.
Yes. And this is why the nvcc preprocessor is so effective at working with the various host compilers. It emulates properties of the host compiler so that the device code and host agree on things.
That is quite interesting. I haven't thought much about source-to-source transformation within C++.
Do you have any articles/papers/books/etc. you can point us to for understanding this better?
Two usecases i have in mind are;
1) Transforming legacy C++98/C++03 codebases into "modern" C++11/14/17/20/23/26. Is this possible with current edg?
2) Adding verification conditions based on code analysis; both runtime contract asserts and compile time proofs (possible?) so as to convert "normal" C++ code into "somewhat verified" C++ code.
I wonder if the source-to-source compilation could be used to transpile C++ code/libraries to other languages - e.g. could this be used (with appropriate modifications of course) to compile FLTK into Free Pascal code and used directly by Lazarus as a backend for LCL? Trying to use C++ libraries from non-C++ is always a PITA, especially if you want to avoid dynamic linking.
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.
Well, Borland had the benefit of being in control of both compilers :-). C++ Builder even had Object Pascal compatible extensions to link against VCL (which was written in Pascal).
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.
Borland made the virtual tables used by C++ and ObjPascal compatible, that's why it was possible to mix the two languages. If the design is different than it becomes a much more difficult problem.
You mean the article in general is 100% LLM, or the arrangement of these four words is 100% LLM?
I find it extremely unlikely LLMs would have the monopoly on this particular word arrangement—and indeed they would have learned it from training material produced by people in the first place.
Ah, I used EDG for static analysis, but joined when we were switching over to using Clang for the frontend. I can't say for sure, but part of it was definitely just to save money using open source. The code that was hacked on top of EDG was also ridiculous, so there was a lot of accumulated tech debt there.
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.
I looked into using static analysis on an ancient Borland C++ codebase some decades ago, I quickly found out that a tiny software shop in New Jersey - Edison Design Group - were, at the time, pretty much the only ones who had modeled enough actual C++ implementation behavior to possibly do meaningful static analysis. (Not as far back as our Borland C++ version though, lol).
Ooh, fond (and some not so fond) memories of when Silicon Graphics' (MIPS) C and C++ compilers were based on EDG's frontend, with a custom ucode-generating backend, and integrated into CASEVision. Early 1990s.
EDG started with two people. When John Spicer joined in 1992, they grew to three. I joined when Mike Anderson retired from software development in 1999, so we were still just three. Mike Miller joined in 2004 to make it four. Mike Herrick in 2007 to make it five. We were briefly seven in the early 2020s, and then fell back to six when Ellen Herrick stepped down. The three youngest of us moved to NVIDIA about a year ago.
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!
> 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):
The weirdest file is the 3M src/unicode_name_fsm.c. Constructing a hardcoded FSM state machine, instead of doing the normal unicode range searches. The range searches can be parallelized, because they are independent. The FSM not. The constructor is at dev_tools/cpp_tools/process_unicode_names/main.cpp
I really want to test this idea.
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).
...
I like this emulation feature. A frontend capable of mimicking MSVC or GCC behavior seems very useful for porting code or developing tools that need to exactly replicate the operation of another compiler.
Despite using C++ for a few years now, the EDG source code is still mostly C code (and in fact, the C++ code is still using the old .c file names). In particular, there's no usage of the C++ standard library.
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).
I think this is fairly common practice when writing compilers. You ideally want to be able to bootstrap from other languages, and C is a much simpler starting point.
Yes, of course. It makes complete sense to have the implementation of a C++ compiler to be written in a highly portable and much simpler language like C.
I'll never forget working on a personal C++ project in the very early 2000s. In parallel, I was reading Bjarne Stroustrup's famous C++ bible. He diligently explained how the “export template” feature worked. I tried to use it. I was compiling with GCC on Linux. I spent days trying to understand why it didn't work. Finally, I found a blog post explaining why it was so hard to implement, and no open source C++ compilers supported it. What a disappointment!
No comment about the substance of the article but I just have to give props: this site loaded incredibly quickly for me. Like it felt like a handful of milliseconds between tapping the link on my phone and it showing up, already scrolled to the right anchor within the article. Bravo on making it snappy.
Indeed - a nice bloat-free site, but it still looks reasonably modern.
I needed the SMBus specification a week or two back, and was greatly amused by the 1990s-looking website which hosts it - still with purple bevelled buttons adorned with Comic Sans text! But it's crawlable, archivable, won't break when some framework or plugin gets automatically upgraded, and will hopefully still be there in another decade.
It has an interesting code style, the comments go _after_ the function definition but before the opening bracket.
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.
I write comments about what a function does and it's interface before, but comments about the implementation after. Also my pre- and post-conditions go there of course. (I'm mostly writing in C.)
One of the more unusual aspects is the naming convention for types. Most type names use the a_ prefix (e.g. a_statement_ptr), but names beginning with a vowel start with an_ instead (e.g. an_object_lifetime_ptr).
Code from that era predates the web, and a lot of open source style guides, and even most open source code itself.
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.
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.
It's one of the 4 big remaining C++ compiler frontends: gcc, clang, MSVC, EDG.
Most other C++ compilers are based on either EDG or clang. (e.g. the Intel C++ compiler used to be based on the EDG frontend, though modern versions are based on clang instead)
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.
No, MSVC is its own front end (the older continuously maintained C++ front end, in fact). However, Visual Studio's C++ IntelliSense uses the EDG front end.
What's not mentioned in the announcement (at least based on a quick skim) is that EDG the company is winding down, which is likely the reason why they're open sourcing the front end.
https://en.wikipedia.org/wiki/Edison_Design_Group ref 9: https://herbsutter.com/2025/11/10/trip-report-november-2025-...
Sad. Those folks are some brilliant computer scientists.
Not really sad. They are getting older, worked for themselves doing presumably what they wanted their entire career, now they are done. They could have built the company up, instead it has been common knowledge for close to 10 years they were going to retire 'any day now.'
Building a company is so fraught with pitfalls, probably realized at some point that their income was good enough that they could safely work towards retiring at some point in the future without problems and drama.
> John was the most vocal person pointing out technical problems with the feature; the committee decided it did not agree and standardized the feature anyway over his and EDG’s sustained objections; and then instead of sitting back and saying “we told you so,” EDG ended up being the only company in the world who ever implemented the feature! To add a sense of proportion: It took the same team longer to implement just the C++98 export template feature than to implement a compiler front-end for the entire Java language. But John and EDG went and did it, to support the committee’s consensus decision… only to have the committee remove export template again a few years later, because John and EDG had been right about the feature’s problems. That’s a model of solid professional behavior.
Yes, but no reflection on the burn out this causes for the c++ community?
EDG has been consistently the most vocal opposers of anything that goes in the language, and in recent years had stopped keeping up. The `export` thign was an exception.
Sorry, but that's nonsense. We've supported plenty of features. We've also occasionally been the first to implement them. In recent years, we spearheaded reflection, supported, first-implemented a bunch of constant-evaluation features (consteval etc.), and supported and first-shipped C++23 "explicit this".
Doesn't make sense. C/C++ static analyzers wouldn't be using EDG if it can't keep up with the language.
Wow. This is big news for C++.
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.
i dont even use cpp and my immediate response was oh shit this is a big deal
> Wow. This is big news for C++.
But also quite sad. They've announced that they are closing down.
It is great news, it means that C++ can slowly wither as other organisms occupy the same niche.
May you be cursed with inheriting a large COBOL application.
Don’t threaten me with a good time and job security.
What is not to like, job security, it is a compiled language, standard is still ongoing (there is even OOP support), one can write microservices in it, there are IDEs, and most relevant, it is still much less English to type than AI Markdown files.
As curses go, not a curse! https://github.com/loveOSS/awesome-cobol
So far, several other organisms rely on C++ code for their own implementation, instead of being bootstraped.
There are essentially four C++ frontends: gcc, clang, MSVC, and EDG. Pretty much every C++ compiler is a reskinned version of one of those compilers. Most of the proprietary compilers have been slinking away from using EDG to using clang (e.g., Intel did this transition a few years ago).
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.
I’m hopeful open sourcing means a new life for EDG.
I wouldn’t hold my breath, but I hope I am wrong
C++ is a sprawling language which will consume any available amount of effort or goodwill. So I don't expect you will see a "new life" for this codebase while continued effort on the "big three" compilers happens.
Well, Microsoft has to finally fix Visual Studio and VSCode Intelisense experience with modules some day.
Now if they upstream the changes is another matter.
Where would that new life come from? As far as I am aware, there isn't exactly a thriving community around it which has been begging for a source release for ages, and with Clang and GCC there hasn't been a shortage of open-source C++ compilers either. And it's not exactly like the C++ ecosystem as a whole is booming, with it not having any answer to the memory safety problem.
From what I can tell this is just some retiring guys who want to make sure their life's work isn't lost to history, and who want to avoid screwing over their handful of remaining customers. Realistically, the best you can hope for is probably the occasional bugfix, and other open-source compilers scavenging it for a handful of useful clever ideas.
Maybe they're hoping the remaining customers will cooperate on keeping it up to speed? I know that f.ex. IAR are building their own backends,etc and might be an EDG customer, the MSVC IDE team aswell, now if they'll manage to get it working is another question but with the code in the open there's a chance at least.
Why not defect to clang? I'm sure some PHB's will suggest that (and that will be part of the survival, convincing those that supporting another party is a good thing).
Standardization does have it's issues, but the JS ecosystem always seems to be healthier when one implementation isn't too dominant. The question is if the C++ ecosystem is large enough to support multiple frontends.
The thing is, who's going to pull the cart? Giving stewardship to a nonprofit is perfectly fine from an IP perspective, and they'll have no trouble finding someone to herd some bugfixes, but what's going to happen when significant refactoring is needed to add support for C++26/29/etc?
Having your resident compiler expert upstream the occasional patch to keep your legacy product from dying is one thing, but which big tech company cares about this specific compiler enough to spin up an entirely new dedicated team for it? And who's going to choose a mostly-abandoned compiler front-end as a core part of a new product?
Sure, it can be done, but for each individual user defecting to clang must be looking very attractive right now.
Wouldn't it be Microsoft, since they rely on it for IntelliSense?
There are fundamental differences in the design of clang and EDG at IR level that would affect whether clang can work for your use cases at all. I don't know enough in this area, so I won't say anything incorrect that would embarrass myself, but that's something you could look into.
I estimate there were very roughly 50 customers in the end. (I was an EDG engineer and didn't work on admin stuff — so it might be off, but not much. I'm estimating based on support tickets origins.) That's down from maybe double that at our max (again, my estimate). I heard of fairly few customers switching to Clang or other projects (Intel being the most notable exception). Most of our customers we "lost" were due to mergers/acquisitions (i.e., two customers suddenly became just one).
This. Maintaining a C++ front end is a lot of hard work that requires expertise -- I wouldn't be surprised if there are a bunch of CS PhDs in the team. You don't just randomly hire someone to work on compilers like with web development. I seriously doubt there will be a lot of contributions coming from the community. Maybe bug fixes, but likely not keeping up with C++ standards.
Well, if you're fine with not being up to date in terms of C++ standards there is also the OpenWatcom C/C++ compiler[0]. Jiří Malák (the main v2 dev) is doing a herculean job maintaining and improving it.
[0] https://github.com/open-watcom/open-watcom-v2
I'm not sure Watcom is C++98 compliant, let alone C++11 or newer
(and I'm implicitly using C++11 here when I say "C++", given that it effectively defines 'modern' C++).
According to some older comment by jmalak, it is compatible with C++98/C++03 with some C++11 features though, yes, it isn't C++11 compatible (there are some stubs for C++11 that i can see in the code but nothing implemented).
And that's a thing though, SFINAE hinted at it but more recent versions of C++ constexpr and consteval together with relaxed constexpr and "if constexpr" and "if consteval" together with compile-time dynamic typing forced the compiler to more or less include an interpreter in the frontend.
Adding some features of C++11 isn't close to building a C++ compiler capable of 11, 14, let alone 17, 20, 23 or 26.
If you can rip out a compliant parser, it might even be better to start over on a new compiler frontend if your current compiler frontend is targeting at pre-11 level.
What about Green Hills?
In my day (2006–2011) Green Hills used EDG's frontend. I have the vague impression they might have already switched away. (I know Intel ICC already switched to Clang a while ago.) I'd be very surprised to learn that GHS had ever developed their own frontend.
I'm surprised it was using EDG. My memory of green hills is that it would regularly crash on valid C++, to the point where I assumed it could only be a shitty homegrown implementation.
> I'd be very surprised to learn that GHS had ever developed their own frontend.
Actually I take that back. At the dawn of time (1982), GHS definitely had its own frontend. They switched to EDG sometime before my time. I meant I'd be surprised to learn they'd switched from EDG to something home-grown.
This also meant that in my time there was a hefty "glue" layer between the EDG frontend and the GHS middle-end (the middle-end being the tree transformations and "indep" optimizations before you got into the back-end stuff): you had to take the structures EDG produced and turn them into the structures the GHS middle-end wanted.
I was there right when John Regehr's Csmith was first making big waves. We started using it, and also rolled our own fuzzer with more focus on embedded-software trouble spots, such as `volatile` and `packed` and I forget what else. (Guy Goldstein originated and led this, as I recall.) I don't actually remember the fuzzer finding a lot of crashes, but maybe it did, and I do remember its finding a lot of miscompilations, i.e., bad optimizations.
I always thought Intel C++ is its own thing, unrelated to the others?
The Intel compiler used to use the EDG frontend; they swiched to Clang a few years ago.
Oracle Studio C++ and IBM XL C++ still exist, but the old front-ends are almost dead. They were both able to achieve partial C++14 support before giving up and choosing a side. Oracle chose GCC, IBM chose Clang.
There are also OrangeC and OpenWatcom-v2.
I might be wrong, but I always assumed that Gimple Lint / PC Lint has its own C++23 frontend too. It looks very different from what other compilers have.
Announcement: https://edgcpp.org/#transition
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
I never knew about the LLVM exception:
I don't understand the second part. Can someone explain it to me?
The Apache's patent clauses conflict with the requirements of the GPL license. GPLv3 contains explicit wording to handle this conflict; GPLv2 does not. The exception here is adding wording to let this Apache-licensed code be used with GPLv2 code in the same way that it would normally be usable with GPLv3.
The "About" from the Github source - https://github.com/edgcpp/compiler
From "The C++ Front End" - https://www.edg.com/c
That last bit is out of date (we didn't work much on keeping the web site up-to-date): The front end is mostly C++23-complete (modules notably lagging), and we have several C++26 feature in as well.
That is great! Thanks for the Update.
Just for others: Again from https://www.edg.com/c
The internal documentation comprises about 600 pages. The "External Interface" chapter of that document, covering command-line options, language dialect issues, and the use of language features like templates, is freely available for downloading in PDF format - https://www.edg.com/docs/edg_cpp.pdf (dated Nov 21, 2025 and hence presumably the latest version)
PS: Maybe these essential info (pointed out in my comments and updated by you) should be front and center in the new edgcpp website.
It's got history! That's really unusual for moves to open-source; the dates on the earliest commits are in 1990 and they do go forward in time so that's really unusual to have that much history. I bet there's some fun stuff in there.
If I remember correctly, EDG was the only C++ implementation that actually attempted to implement the export keyword for templates in old C++. It was this implementation experience that informed the deprecation of export. EDG is a major influence in the development of C++.
Yes, it was also where C++26 static reflection was prototyped, as another example of its influence.
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.
Slight correction, the other compiler/front end writers more or less read the white paper and said "that is what we thought it would be like and thus why we didn't implement it".
Imagine telling your competitors not to copy some feature you have and them listening!
Prof. John Potter told me they were the only frontend that correctly implement multiple inheritance for c++98. He thought very highly of EDG... For old time c++ folks, he was a mod on comp.lang.c++.moderated and a very cool teacher. So I hope I remember his lessons correctly...
Oh, you had him as a teacher? That's awesome. I met him and his family 25+ years ago while they were vacationing in California... and they were all great! He was also at the Morristown WG21 meeting, where C++98 was voted out (in November 1997). (I co-moderated comp.lang.c++.moderated with John. For several years he was the person that kept it alive.)
He was my advisor during undergrad; I had him for everything like C++, Assembly, data structures, operating systems, systems programming, an independent study, and he put me on the path to Unix guru.
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...
It warms my heart to hear it!
Just curious, was she happy or unhappy about that promise?
Pretty easy promise to keep :)
He was my advisor in college
Me too.
One interesting thing about the EDG front end is that it can emulate all the others (and in various versions of the others) and what they support, and the errors they might detect.
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.
what do you mean under "emulation"? and why EDG is frontend? It's not a full compiler with optimizations and code generation?
No, we only parse the language, do full semantic analysis, and optionally lower the representation to something that roughly matches C-language semantics. (That lowering can do some minimal inlining if needed, but that's a historical 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.
What are some usecases for C++ source-to-source transformations ?
Several of our customers instrument the AST to add security-probing and/or other dynamic-analysis features. NVCC uses it to separate out "device" constructs.
Wait, nvcc uses EDG?
Yes. And this is why the nvcc preprocessor is so effective at working with the various host compilers. It emulates properties of the host compiler so that the device code and host agree on things.
You can see some discussion here:
https://forums.developer.nvidia.com/t/nvcc-preprocessing/649...
That is quite interesting. I haven't thought much about source-to-source transformation within C++.
Do you have any articles/papers/books/etc. you can point us to for understanding this better?
Two usecases i have in mind are;
1) Transforming legacy C++98/C++03 codebases into "modern" C++11/14/17/20/23/26. Is this possible with current edg?
2) Adding verification conditions based on code analysis; both runtime contract asserts and compile time proofs (possible?) so as to convert "normal" C++ code into "somewhat verified" C++ code.
Some resources that Google brought up;
Challenges and Opportunities in C/C++ Source-To-Source Compilation - https://drops.dagstuhl.de/entities/document/10.4230/OASIcs.P...
C++ Insights - See your source code with the eyes of a compiler - https://github.com/andreasfertig/cppinsights Tool at https://cppinsights.io/
https://news.ycombinator.com/item?id=49919630
I wonder if the source-to-source compilation could be used to transpile C++ code/libraries to other languages - e.g. could this be used (with appropriate modifications of course) to compile FLTK into Free Pascal code and used directly by Lazarus as a backend for LCL? Trying to use C++ libraries from non-C++ is always a PITA, especially if you want to avoid dynamic linking.
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.
Borland compilers used to allow the mixing of C++ and Pascal code, so it is technically possible.
Well, Borland had the benefit of being in control of both compilers :-). C++ Builder even had Object Pascal compatible extensions to link against VCL (which was written in Pascal).
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...
Borland made the virtual tables used by C++ and ObjPascal compatible, that's why it was possible to mix the two languages. If the design is different than it becomes a much more difficult problem.
They still do, only it is Embarcadero now.
https://www.embarcadero.com/products/rad-studio
I think so, you'll have to translate their AST/IL to freepascal.
"Three tracks, one codebase" this is such an LLM written sentence.
EDIT: But in this case it seems something significant is being released, it would be better with less writing and more human if possible.
I hate that now every catchy phrase are considered llm written.
llm overused them, but llm got its training data from catchy marketing materials and youtubers
Any human digital creation now actually.
This isn't a catchy sentence though; it's clearly an LLM. I've read enough LLM writing, and this is it 100%
You mean the article in general is 100% LLM, or the arrangement of these four words is 100% LLM?
I find it extremely unlikely LLMs would have the monopoly on this particular word arrangement—and indeed they would have learned it from training material produced by people in the first place.
Ah, I used EDG for static analysis, but joined when we were switching over to using Clang for the frontend. I can't say for sure, but part of it was definitely just to save money using open source. The code that was hacked on top of EDG was also ridiculous, so there was a lot of accumulated tech debt there.
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.
I looked into using static analysis on an ancient Borland C++ codebase some decades ago, I quickly found out that a tiny software shop in New Jersey - Edison Design Group - were, at the time, pretty much the only ones who had modeled enough actual C++ implementation behavior to possibly do meaningful static analysis. (Not as far back as our Borland C++ version though, lol).
Ooh, fond (and some not so fond) memories of when Silicon Graphics' (MIPS) C and C++ compilers were based on EDG's frontend, with a custom ucode-generating backend, and integrated into CASEVision. Early 1990s.
EDG was just 3 guys back then.
Wikipedia claims they have 6 employees, so they didn't exactly enjoy exponential growth over the years ;)
EDG started with two people. When John Spicer joined in 1992, they grew to three. I joined when Mike Anderson retired from software development in 1999, so we were still just three. Mike Miller joined in 2004 to make it four. Mike Herrick in 2007 to make it five. We were briefly seven in the early 2020s, and then fell back to six when Ellen Herrick stepped down. The three youngest of us moved to NVIDIA about a year ago.
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!
> 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):
This is what i want to do in my life too!
The weirdest file is the 3M src/unicode_name_fsm.c. Constructing a hardcoded FSM state machine, instead of doing the normal unicode range searches. The range searches can be parallelized, because they are independent. The FSM not. The constructor is at dev_tools/cpp_tools/process_unicode_names/main.cpp I really want to test this idea.
For the uninitiated, what are/were the strong points of this frontend wrt the others? Why would anyone use it?
I'm one of the former EDG engineers...
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). ...
https://news.ycombinator.com/item?id=49919630
I like this emulation feature. A frontend capable of mimicking MSVC or GCC behavior seems very useful for porting code or developing tools that need to exactly replicate the operation of another compiler.
Despite using C++ for a few years now, the EDG source code is still mostly C code (and in fact, the C++ code is still using the old .c file names). In particular, there's no usage of the C++ standard library.
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).
I think this is fairly common practice when writing compilers. You ideally want to be able to bootstrap from other languages, and C is a much simpler starting point.
Yes, of course. It makes complete sense to have the implementation of a C++ compiler to be written in a highly portable and much simpler language like C.
They also have a distinct style/naming convention, see for example `a_list_entry` as type name.
I have fond memories of working on an embedded systems compiler that used the EDG front-end — that would be almost 20 years ago now.
We certainly held it in high regard. It was rare that a compiler bug was in their code rather than ours :).
The only implementation to ever support the C++98 “export template” feature, as far as I know. I wonder if that’s still in the open-sourced version.
I'll never forget working on a personal C++ project in the very early 2000s. In parallel, I was reading Bjarne Stroustrup's famous C++ bible. He diligently explained how the “export template” feature worked. I tried to use it. I was compiling with GCC on Linux. I spent days trying to understand why it didn't work. Finally, I found a blog post explaining why it was so hard to implement, and no open source C++ compilers supported it. What a disappointment!
what this keyword did? I never heard of it
It allowed you to put the _definitions_ of your function templates in your ".cpp" files instead of your header files.
Some info here: https://en.wikipedia.org/wiki/Template_(C%2B%2B)#Exported_te...
I remember this was also used by SN Systems (Sony at the time) as the frontend in their C++ compiler for systems like the PS Vita and PS3.
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.
No comment about the substance of the article but I just have to give props: this site loaded incredibly quickly for me. Like it felt like a handful of milliseconds between tapping the link on my phone and it showing up, already scrolled to the right anchor within the article. Bravo on making it snappy.
I wonder what advanced technology they used to make it so fast?
Something like, oh, I don't know - HTML?
Indeed - a nice bloat-free site, but it still looks reasonably modern.
I needed the SMBus specification a week or two back, and was greatly amused by the 1990s-looking website which hosts it - still with purple bevelled buttons adorned with Comic Sans text! But it's crawlable, archivable, won't break when some framework or plugin gets automatically upgraded, and will hopefully still be there in another decade.
[1] smbus.org
Oh wow, it even looks like they support far/near pointers from the old DOS days!
It has an interesting code style, the comments go _after_ the function definition but before the opening bracket.
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.
This is also where conditions go in languages with contracts, I like it
This is common in Lisps.
never occurred to me to write a comment there, but it actually looks kind of clean imho. Really old C code looked like
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:
I write comments about what a function does and it's interface before, but comments about the implementation after. Also my pre- and post-conditions go there of course. (I'm mostly writing in C.)
One of the more unusual aspects is the naming convention for types. Most type names use the a_ prefix (e.g. a_statement_ptr), but names beginning with a vowel start with an_ instead (e.g. an_object_lifetime_ptr).
Code from that era predates the web, and a lot of open source style guides, and even most open source code itself.
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.
You got me thinking about C/C++ style guides of my youth...
I think Indian Hill (C, not C++) was the first one I ever read: https://www2.cs.arizona.edu/~mccann/cstyle.html
Looks like there is an updated version (1997) here: https://www.cs.cornell.edu/people/egs/comp303/tutorials/csty...
Paul Haeberli's "The SGI C Source Compliance Requirements" is hard to forget: https://www.graficaobscura.com/ccode/index.html
I wonder whether there is a centralised historical archive of C/C++ style guides?
The modern staples are covered here, I guess:
https://github.com/kciter/awesome-style-guide#cpp
I've seen that in other code bases. Can't think of them offhand right now.
Numerical Recipes in C does that.
Numerical Recipes in C is an existence proof of the adage that the determined FORTRAN programmer can write FORTRAN in any language.
(Using FORTRAN here rather than the more correct Fortran to denote the traditional pre-modern (Fortran 90+) programming style.)
What is this?
https://en.wikipedia.org/wiki/Edison_Design_Group
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.
It's one of the 4 big remaining C++ compiler frontends: gcc, clang, MSVC, EDG. Most other C++ compilers are based on either EDG or clang. (e.g. the Intel C++ compiler used to be based on the EDG frontend, though modern versions are based on clang instead)
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.
> 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
https://en.wikipedia.org/wiki/Cfront
Isn't MSVC EDG frontend?
No, MSVC is its own front end (the older continuously maintained C++ front end, in fact). However, Visual Studio's C++ IntelliSense uses the EDG front end.