4 ms·

Yeah, I used ironically the apocalypse word, that to highlight the fact the damage is seriously high. I often push the envelop to call gcc/clang "backdoor gener

Yeah, I used ironically the apocalypse word, that to highlight the fact the damage is seriously high. I often push the envelop to call gcc/clang "backdoor generators" (even though nowadays, it seems it is more likely to be hidden in the supply chain/SDK). For me gcc is in /opt, as it's over: this is "open source" not worth more than a binary blob... which generates machine code for EVERYTHING... baw... hurt. And it seems we are more and more to understand how critical _lean_ is for open source software (and file formats/network protocols), _including the SDK namely the computer languages_. Real-life alternatives or deep customizations are way harder to build without _lean_ software. A good example: web "app" and web "site". web "app" is javascript requiring one of the massive whatng cartel web engines. web "site" is classic or noscript/basic (x)html (aka basic 2D/table based HTML forms only, with a clean CSS/presentation split). Also, I should be able to bootstrap, and that reasonably, a full elf/linux based OS with a simple C compiler (assembler+linker), for instance cproc/scc/tinycc/etc. gcc being now c++ broke everything, and I cannot believe the MIT media lab/"gcc steering commitee" did not know that, and the rumors of B.Gates interfering at "MIT medialab" via Epstein funding would explain open source quality obvious sabotage decision making. All that said, I think it is game over, and we should move toward RISC-V assembly written programs sided with high-level languages (python/ruby/shell/javascript only engine/etc) with RISC-V assembly written interpreters, with a very conservative usage of macro preprocessing (because some preprocessors may reach c++ and similar complexity and that would not be much better than the current state). I am currently coding basic rv64 assembly (no pseudo-instructions, only core ISA, using a basic C preprocessor). I have a littele rv64 interpreter to run them on x86_64... well, until the programs stay simple enough.

uecker 1y ago
I don't see why you think the gcc steering committee is related to MIT and the rest also sounds more like a conspiracy theory. In any case, there is still a path open for bootstrapping via TCC / GCC 4.8 ... C++ - in general - is just the mistake of the overall trend in the industry to add overly complex nonsense.
- pjmlp 1y ago
  Still waiting for the mythical day WG14 will manage to standardize safe arrays and strings types on the standard library as C++.
  - sylware 1y ago
    We are not talking about that actually.
    - pjmlp 1y ago
      Actually we are, because that is one of the reasons why C++ should be used instead of C. Although ideally both should have been replaced by now.
      - uecker 1y ago
        I would say that C++ pulls in so much entropy, that having standardized array and string types does not really make up for it. And the standardized arrays are not even safe in C++: https://godbolt.org/z/Y4f4v8M3z https://godbolt.org/z/Y4f4v8M3z
        pjmlp 1y ago
        Because you ignored on purpose the at() method. https://godbolt.org/z/6PY1ve8ev https://godbolt.org/z/6PY1ve8ev Or to use one of the beloved compiler extensions, https://godbolt.org/z/6KKjcM7bP https://godbolt.org/z/6KKjcM7bP Additionally these extensions are now part of C++ as soon C++26 gets ratified, given that P3471R4 has been accepted. Whereas in C that isn't even an option.
        uecker 1y ago
        I haven't seen at() used a lot and simply using C++ and C would not make your programs magically use at() instead []. P3471 is not required to be supported by an implementation, and bounds checking extensions also exist for C.

uecker 1y ago

I don't see why you think the gcc steering committee is related to MIT and the rest also sounds more like a conspiracy theory. In any case, there is still a path open for bootstrapping via TCC / GCC 4.8 ... C++ - in general - is just the mistake of the overall trend in the industry to add overly complex nonsense.

pjmlp 1y ago
Still waiting for the mythical day WG14 will manage to standardize safe arrays and strings types on the standard library as C++.
- sylware 1y ago
  We are not talking about that actually.
  - pjmlp 1y ago
    Actually we are, because that is one of the reasons why C++ should be used instead of C. Although ideally both should have been replaced by now.
    - uecker 1y ago
      I would say that C++ pulls in so much entropy, that having standardized array and string types does not really make up for it. And the standardized arrays are not even safe in C++: https://godbolt.org/z/Y4f4v8M3z https://godbolt.org/z/Y4f4v8M3z
      - pjmlp 1y ago
        Because you ignored on purpose the at() method. https://godbolt.org/z/6PY1ve8ev https://godbolt.org/z/6PY1ve8ev Or to use one of the beloved compiler extensions, https://godbolt.org/z/6KKjcM7bP https://godbolt.org/z/6KKjcM7bP Additionally these extensions are now part of C++ as soon C++26 gets ratified, given that P3471R4 has been accepted. Whereas in C that isn't even an option.
        uecker 1y ago
        I haven't seen at() used a lot and simply using C++ and C would not make your programs magically use at() instead []. P3471 is not required to be supported by an implementation, and bounds checking extensions also exist for C.