It is very well explained? GCC and Clang would be nightmares to integrate into an app that runs on many platforms including iOS, and even once you did, you'd still need to implement an interpreter, because you're not allowed to JIT on the app store. Compiling a toolchain for a desktop platform is easy. Cross compiling a toolchain is moderately easy. But embedding a toolchain into an iOS app, where you have to get it and all of its dependencies compiling for iOS, definitely seems like a massive challenge.

For Clang/LLVM, it wouldn’t be that hard. It’s one source tree to build (Clang is in a separate repo from LLVM core, but you check it out into a specific subdirectory and they build together), all C++, no external dependencies, and the result is a set of static libraries you can easily link into an iOS app.

As for interpreting — there are a few options. The simplest approach would be to use LLVM‘s built-in IR interpreter (lli), which did exist in 2010.

Alternately, if you want more control: these days, the targets supported by upstream LLVM include:

- eBPF

- WebAssembly

- AVR

The first two are bytecode formats, both designed for (relative) simplicity and portability. There are open-source interpreters available for both, or alternately they’re both simple enough that you could relatively easily write your own. AVR, on the other hand, is the actual instruction set used by the Arduino; I’m not sure what the status is of open-source AVR emulators (I see a few projects on GitHub but don’t know how good or complete they are), but there’s probably something out there that would work.

But to be fair, all three of those targets were merged into LLVM upstream only recently, much later than 2010. Also, 2010 was the year that Clang got C++ support working well enough to become self-hosting, according to Wikipedia [1]; it was still relatively experimental, not nearly as much of a “safe bet” as it is today. (Still, even then, it was pretty much guaranteed to work better than writing your own C++ compiler from scratch! :p)

GCC is older but much harder to embed, even today. For one thing, it’s under the GPL. iCircuit is closed source, and even if the author were willing to open it, there are supposedly legal issues with publishing GPL code to the App Store. And there are technical obstacles as well: last I checked, GCC still expects to be run as the main executable as part of a traditional Unix toolchain, not embedded as a library. If that has changed, it was only recently.

[1] https://en.m.wikipedia.org/wiki/Clang#Status_history

Honestly, Clang does seem like it would be pretty easy to embed in comparison. They do mention their app is written in C#, and integrating C++ code with it on every platform may carry its own challenges. I know it's relatively easy to do with desktop platforms with Mono and Microsoft .NET just using normal PInvoke, but have no idea about iOS; code signing looks complicated on iOS, though I'm sure you know it inside and out. Either way... yeah, if you consider Clang, it really does appear like a waste of time to write your own C++ compiler, even for just a subset.

If they integrated Clang, then they could use Clang to compile code to WebAssembly, which can be executed by iOS's Javascript engine and pre-processed by wasm-metering[0] to set execution op limits so infinite loops can be recovered from.

[0] https://github.com/ewasm/wasm-metering

Why people still use stupid Apple products which unbelievably forbid the certain computation on the machine we own(except we don't) and have complete control of(also we don't).

> Please don't call it C++ if it doesn't even support constructors and destructors.

At least they recognize this is missing, and call it out.

> Why not use GCC or LLVM as part of your project? That seems like a better investment of your time.

Learning opportunity? Maybe they're trying to solve a problem? Or do you think the LLVM folks should have just used GCC instead of wasting their time on LLVM?

Aren't constructors and destructors basically the main idea of c++?

C++ is too big to have any "main feature", but in any case yeah, it's a huge deal.

> Why not use GCC or LLVM as part of your project?

That's not how the world gets compiler people.

Someone had to write GCC and LLVM, and someone will have to write whatever comes next. Languages and tooling only advance because there are those who choose to take the hard road instead of "just using that thing that someone else made".

The successor to LLVM isn't going to be written by someone just hacking on an app and decides they could use a basic compiler. It's going to be written by someone who has the explicit goal of replacing LLVM, fully understands LLVM's design and tradeoffs, and has ideas about an architecture for a successor that improves on the design.

Encouraging people to use LLVM instead of home-growing a toy compiler can still get you compiler people. LLVM is just the backend, not the frontend, so you still need to write the compiler frontend yourself, and once you've learned LLVM, if you're so inclined you may start hacking on LLVM and therefore become a backend compiler person too.

> Hello everybody out there using minix -

> I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones.

—Linus Torvalds, in a post[1] to comp.os.minix, 25 August 1991 (emphasis mine)

[1]: https://groups.google.com/forum/#!msg/comp.os.minix/dlNtH7RR...

> It's going to be written by someone who has the explicit goal of replacing LLVM, fully understands LLVM's design and tradeoffs, and has ideas about an architecture for a successor that improves on the design.

And from where would they get those ideas? Tweaking LLVM is not enough to learn the necessary trade-offs. You need to write a compiler from the ground up. In fact you need to do it multiple times. Most likely you will not end up writing a LLVM replacement. Most likely you will end up a better programmer.

Most compilers use not one internal IR, but rather a successive series of IRs. LLVM itself has its normal IR layer, plus a machine IR layer for actually generating code for targets. Plus another layer (two actually, you can pick which one you want) for going between LLVM IR to machine IR. Most programming language frontends have their own IR (or two) that they use in between the AST and something like LLVM IR.

The genius of LLVM is that it's a stable, well-defined IR layer in the middle of the compilation stack that lets you switch out either the frontend or the backend without having to do the entire messy, boring, critical implementation of the other piece. And you can support pretty wacky frontend languages or pretty wacky backends (people compile LLVM to C source or FPGAs, for example).

Not really that much of a genius, given that IBM was already using the same architecture on their RISC compilers research during the 70's.

Check the papers related to PL.8 compiler architecture.

Am I seeing things or there's a recent trend of claiming things are C++ compilers when they're nowhere near that?

Just yesterday there was this, which doesn't even support structs:

https://news.ycombinator.com/item?id=17843293

I'm all for simple instructive projects, but we don't need to describe them in such misleading ways.

Indeed, for a moment I thought that someone had actually figured out how to condense the C++ standard enough to write a full compiler for it, like we've seen many times here on HN with C/C subset compilers.

It's more accurately a "C superset" compiler, or perhaps "C+".

Integrating LLVM requires quite a lot of mental effort (Let's not even discuss GCC...), whereas writing from scratch can be "simpler" mentally (at least to start with).

The destructors happen to be one of the most important features that distinguishes C++ from C imho (automatic cleanup at end of scope), so would be great to implement those!

> People will be trying to port their existing code, and will be unpleasantly surprised.

I agree with you 100%, but this made me laugh.