4 ms·

Ultimately, the plan for Cwerg is to be self-hosting, so C++ is just another stepping stone. I am curious about the issues with C++17 (vs say C++11) though. Ab

Ultimately, the plan for Cwerg is to be self-hosting, so C++ is just another stepping stone. I am curious about the issues with C++17 (vs say C++11) though. About using C++: Cwerg is NOT going "all in" on C++ and tries to use as little STL as possible. There are some warts here and there that C++17 fixes and those are used by Cwerg - nothing major. There is also a lightweight C wrapper for Cwerg Backend. About not using C: I do not get the fetishizing of C. String handling is just atrocious, no concept of a span, no namespaces, poorer type system, etc. Cwerg is actually trying to fix these. If Cwerg was written in C instead of C++, a lot of the constructs would become MACRO-magic. About Backends: Currently supported are: 64 bit ARM, 32 bit ARM (no thumb), 64 bit x86 There are no plans to support 32 bit x86

Rochus 2y ago
> I am curious about the issues with C++17 (vs say C++11) though. It's about dependability and bootstrapping. GCC 4.7 was the last version implemented in C, and it supports C++98/03 and a subset of C++11. > There are some warts here and there that C++17 fixes [..] nothing major But it's C++17 and thus requires many more bootstrap cycles until we have a compiler. I think a backend which only supports a subset of the features of a C++17 compiler should not depend on C++17, otherwise its usefulness is restricted by the availability of such a compiler. > I do not get the fetishizing of C. String handling is just atrocious... C is just a pretty primitive high-level language (with a very strange syntax) a compiler of which exists on almost any system. The next complexity step is C++98 (or the subset supported by cfront), which solves your issues and is even good enough to build something as complex as Qt and KDE. > There are no plans to support 32 bit x86 Ok, thanks. The support for ARM32 already enables many use cases.
- muth02446 2y ago
  I can commiserate. I did some bootstrapping of gcc 10 years ago and it was the most miserable experience ever. You make a change somewhere. Kick off "make" and 20 min later you get some bizarre error in some artifact that is hard to find, generated by a build system that is impossible to trace. A self-hosting Cwerg will hopefully be much easier to bootstrap because of its size. But until then, why do you need the (continuous) bootstrapping. You can use a cached version of the bootstrapped C++ compiler or cross compile.
  - Rochus 2y ago
    I didn't express a requirement for Cwerg, but just tried to explain why I prefer to implement a compiler in C++98 than C++17.

Rochus 2y ago

> I am curious about the issues with C++17 (vs say C++11) though. It's about dependability and bootstrapping. GCC 4.7 was the last version implemented in C, and it supports C++98/03 and a subset of C++11. > There are some warts here and there that C++17 fixes [..] nothing major But it's C++17 and thus requires many more bootstrap cycles until we have a compiler. I think a backend which only supports a subset of the features of a C++17 compiler should not depend on C++17, otherwise its usefulness is restricted by the availability of such a compiler. > I do not get the fetishizing of C. String handling is just atrocious... C is just a pretty primitive high-level language (with a very strange syntax) a compiler of which exists on almost any system. The next complexity step is C++98 (or the subset supported by cfront), which solves your issues and is even good enough to build something as complex as Qt and KDE. > There are no plans to support 32 bit x86 Ok, thanks. The support for ARM32 already enables many use cases.

muth02446 2y ago
I can commiserate. I did some bootstrapping of gcc 10 years ago and it was the most miserable experience ever. You make a change somewhere. Kick off "make" and 20 min later you get some bizarre error in some artifact that is hard to find, generated by a build system that is impossible to trace. A self-hosting Cwerg will hopefully be much easier to bootstrap because of its size. But until then, why do you need the (continuous) bootstrapping. You can use a cached version of the bootstrapped C++ compiler or cross compile.
- Rochus 2y ago
  I didn't express a requirement for Cwerg, but just tried to explain why I prefer to implement a compiler in C++98 than C++17.