4 ms·

I disagree with the idea of using C++. Even with some of its more modern features. If I was choosing a compiled language for system development right now I woul

by anfilt 6y ago

I disagree with the idea of using C++. Even with some of its more modern features. If I was choosing a compiled language for system development right now I would choose C or Rust. For starters C++ does not have a stable ABI. Rust plans too have a stable ABI. In either case right now both fall back to the C ABI, but at least its a goal of the rust devs. C++ is going to be harder to boot strap than either Rust core or C when trying to build a compiler for a new system/platform. C probably is the easiest bootstrap of the 3. Rust and C are generally more performant than C++ code. Also in the realm of low end micro controllers C code tends to have the smallest binary image size. In C++ if you need to interact with other languages a lot times your stuck to the C abi which which forces you to avoid a lot C++ features/constructs. As for rust its not an object orientated language and its unsafe blocks generally make it easier to at least keep rust code idiomatic. C++ is also a massive kitchen sink of a language with many ways to hide gotchas. Probably the worst thing in C is its null terminated strings but C++ also suffers from that. C is simple, and rust has at least so far made good design choices for the most part. There also choices in the C++ language that are even part of the standard library that seemed like a good idea but with hind sight are not that great of idea. For example operator overloading. Although we are talking a GCC front end so I would be surprised to see both C and C++.

eru 6y ago
> If I was choosing a compiled language for system development right now I would choose C or Rust. I'm not quite sure what systems development has to do with compiler writing? (I assume by system development, you mean something like writing OS kernels etc?) Eg there are good reasons to stay away from automatic memory management when you are writing an OS, you want control over that. But those reasons hardly apply when you run a simple user space program like a compiler.
- anfilt 6y ago
  System programs can be in user space for instance a run time for another language. As for a compiler ideally its easy to port as its kinda of the bed rock to get any other system going. Although a compiler for some architecture or use cases is too large to be self hosted or does not make sense to be self hosted. So its not always a deal breaker for a compiler.
  - ncmncm 6y ago
    You seem to be confused about what C++ and C are, and even about what Gcc is and its relationship to programs it compiles. C++ is a language defined by ISO committee SC22/WG21 via the Standards 14882, most recently C++20 (superseding C++17). C is defined by SC22/WG14, in the same way. The most widely used implementations of these Standards -- Gcc, Clang, and MSVC -- are in fact the same project in each case (although MS's [until recently implemented] a long-superceded C Standard), and are, in fact, themselves C++ programs. Portability of compilers is not needed, in general, to "get a system going", because cross-compilation is a mature and long-supported technique. Gcc is very frequently ported anyway, for practical reasons, via cross-compilation. Being coded in C++, and capable of compiling and cross-compiling itself, Gcc remains quite portable, as is repeatedly demonstrated by notedly frequent ports. It is hard to imagine what could be considered a "deal-breaker" in this context. By the evidence, portability of C++ is never a dealbreaker as implementation language for a compiler, as in fact the compilers actually used in "get[ting] any other system going" are, with only rare exceptions, compilers in fact coded in C++. (Exceptions are found not to be about portability, but about the memory footprint of the resulting compiler, which is not a product of its source language, but rather of the power of the compiler's optimizer, which is not always seen as necessary.) In any case, the implementation language used for the compiler has absolutely no effect on the stability of an ABI for any target language. ABI stability is a choice made by language designers to favor backward link-compatibility over convenient expression of new features or bug fixes. It is hard for me to imagine the level of confusion that would produce this error.
    - pjmlp 6y ago
      > although MS's implements a long-superceded C Standard). Not anymore, as of 2020, MVSC supports C11 and C17, with the exception of the C99 features that were dropped in C11, like VLAs. Previously they were only keeping up with the ISO C features required by ISO C++ compatibility requirements.
    - eru 6y ago
      > The most widely used implementations of these Standards -- Gcc, Clang, and MSVC -- are in fact the same project in each case (although MS's [until recently implemented] a long-superceded C Standard), and are, in fact, themselves C++ programs. Yes. Though as far as suitability for 'systems programming' is concerned they might as well be Python programs or bash scripts, as long as they produce suitable output in an adequate amount of time.
jandrewrogers 6y ago
Where did you ever get the idea that C and Rust are more performant than C++ code? Modern C++ produces the fastest code of any language in wide use, empirically, and I don’t think many people would argue that. People don’t use C++ because they love its elegance — who would? — they use it for its raw power and expressiveness. C has not been used for applications where performance is a priority for many years now. C lacks the expressiveness to make many software optimizations practical. I’ve written database engines in both C and modern C++ and it is no contest, C++ is much more concise while producing faster code. People primarily still use C for portability.

by anfilt 6y ago

eru 6y ago

> If I was choosing a compiled language for system development right now I would choose C or Rust. I'm not quite sure what systems development has to do with compiler writing? (I assume by system development, you mean something like writing OS kernels etc?) Eg there are good reasons to stay away from automatic memory management when you are writing an OS, you want control over that. But those reasons hardly apply when you run a simple user space program like a compiler.

anfilt 6y ago
System programs can be in user space for instance a run time for another language. As for a compiler ideally its easy to port as its kinda of the bed rock to get any other system going. Although a compiler for some architecture or use cases is too large to be self hosted or does not make sense to be self hosted. So its not always a deal breaker for a compiler.
- ncmncm 6y ago
  You seem to be confused about what C++ and C are, and even about what Gcc is and its relationship to programs it compiles. C++ is a language defined by ISO committee SC22/WG21 via the Standards 14882, most recently C++20 (superseding C++17). C is defined by SC22/WG14, in the same way. The most widely used implementations of these Standards -- Gcc, Clang, and MSVC -- are in fact the same project in each case (although MS's [until recently implemented] a long-superceded C Standard), and are, in fact, themselves C++ programs. Portability of compilers is not needed, in general, to "get a system going", because cross-compilation is a mature and long-supported technique. Gcc is very frequently ported anyway, for practical reasons, via cross-compilation. Being coded in C++, and capable of compiling and cross-compiling itself, Gcc remains quite portable, as is repeatedly demonstrated by notedly frequent ports. It is hard to imagine what could be considered a "deal-breaker" in this context. By the evidence, portability of C++ is never a dealbreaker as implementation language for a compiler, as in fact the compilers actually used in "get[ting] any other system going" are, with only rare exceptions, compilers in fact coded in C++. (Exceptions are found not to be about portability, but about the memory footprint of the resulting compiler, which is not a product of its source language, but rather of the power of the compiler's optimizer, which is not always seen as necessary.) In any case, the implementation language used for the compiler has absolutely no effect on the stability of an ABI for any target language. ABI stability is a choice made by language designers to favor backward link-compatibility over convenient expression of new features or bug fixes. It is hard for me to imagine the level of confusion that would produce this error.
  - pjmlp 6y ago
    > although MS's implements a long-superceded C Standard). Not anymore, as of 2020, MVSC supports C11 and C17, with the exception of the C99 features that were dropped in C11, like VLAs. Previously they were only keeping up with the ISO C features required by ISO C++ compatibility requirements.
  - eru 6y ago
    > The most widely used implementations of these Standards -- Gcc, Clang, and MSVC -- are in fact the same project in each case (although MS's [until recently implemented] a long-superceded C Standard), and are, in fact, themselves C++ programs. Yes. Though as far as suitability for 'systems programming' is concerned they might as well be Python programs or bash scripts, as long as they produce suitable output in an adequate amount of time.

jandrewrogers 6y ago

Where did you ever get the idea that C and Rust are more performant than C++ code? Modern C++ produces the fastest code of any language in wide use, empirically, and I don’t think many people would argue that. People don’t use C++ because they love its elegance — who would? — they use it for its raw power and expressiveness. C has not been used for applications where performance is a priority for many years now. C lacks the expressiveness to make many software optimizations practical. I’ve written database engines in both C and modern C++ and it is no contest, C++ is much more concise while producing faster code. People primarily still use C for portability.