81–90 of 114 posts
Earlier quoted context omitted.
No, many people chose C, because they had to.
Yeah but those people are running it on some platform where it’s the only choice. And they are probably running a subset of C99. The likelihood of new features ever making it to those platforms is close to zero.
Earlier quoted context omitted.
Most single C implementations have died out. There is hardly any C compiler worth using that isn't equally a C++ compiler . In fact, there is any C compiler left worth using that hasn't been rewriten into C++.
There seems to be at least 2 lcc forks (lcc-win32/win64, and pelles-c) that have their own small communities. Although maybe they are dead.
Earlier quoted context omitted.
Most single C implementations have died out. There is hardly any C compiler worth using that isn't equally a C++ compiler . In fact, there is any C compiler left worth using that hasn't been rewriten into C++.
My current C compiler is implemented in D :-)
Earlier quoted context omitted.
> The vast majority of C programmers will agree that they don't care for any of the new features,(...) I think this belief is based on faulty assumptions, such as survivorship bias. C++ became popular largely because it started off by extending C with the introduction of important features that the developer community wanted to use. The popularity of C++ over C attests how much developers wanted to add features to C.…
> So to claim that the C programmers do not want change, first you need to ignore the vast majority that do want but already dropped C... Good, we can ignore them. It's not a language for everybody, and if you're happily using C++, or Zig, or Nim, keep doing that. Developer experience is a weigted sum of many variables. For you cool syntax features may play a huge role of that, for most C programmers a simple languag…
Who do you think you're representing? At best you only speak for yourself. It's perfectly fine if you choose to never update any tool you use, but that's just your personal opinion. You are free to stick with older standard versions of even compiler releases, but that is no justification to prevent everyone around you to improve their developer experience.
> It's not a language for everybody (...)
You might believe it isn't, but that's hardly a sane or rational belief.
Earlier quoted context omitted.
> The vast majority of C programmers will agree that they don't care for any of the new features,(...) I think this belief is based on faulty assumptions, such as survivorship bias. C++ became popular largely because it started off by extending C with the introduction of important features that the developer community wanted to use. The popularity of C++ over C attests how much developers wanted to add features to C.…
> So to claim that the C programmers do not want change, first you need to ignore the vast majority that do want but already dropped C... Good, we can ignore them. It's not a language for everybody, and if you're happily using C++, or Zig, or Nim, keep doing that. Developer experience is a weigted sum of many variables. For you cool syntax features may play a huge role of that, for most C programmers a simple languag…
I think it should have been simple enough to find examples, though I suppose there might be some dependence on what you mean by "useful".
For standalone stuff, some examples might be Ripgrep, ruff, uv, Alacritty, and Polars. Rust is also used internally by some major companies, such as Amazon, Dropbox, Mozilla, Microsoft, Google, Volvo, Discord, and CloudFlare.
Earlier quoted context omitted.
It was proposed by Walter and denied by Stroustroup, probably to save C++. Karma hits back and he is trying to save C++ from Rust.
D is the result of lack of interest by the C++ committee, and I had little interest in spending literally years trying to get useful things adopted into C++. Ironically, over the years, C++ has adopted many features popularized by D. (like contracts!) C++ should adopt a few more D features, like https://www.digitalmars.com/articles/C-biggest-mistake.html , compile time expression evaluation (C++ did it wrong), forwar…
I think you are leaving out the fact that your comment applies to the post-C++98/pre-C++11 hiatus.
Once C++11 was released, the truth of the matter is that whatever steam D managed to build up, it fizzed out.
I'm also not sure if it's accurate to frame the problem with C++0x as picking up features from D. As I recall, D's selling point was that it was scrambling to provide the features covered by C++0x but users weren't forced to wait for a standard to be published to be able to use them. Once they could, there was no longer any compelling reason to bother with D anymore.
Earlier quoted context omitted.
> The complexity of C# and C++ should be a warning, not something to strive towards. I think this talk about "complexity" is a red herring. C++ remains one of the most popular languages ever designed, and one of the key reasons is that since C++11 the standardization effort picked up steam and started including features that the developer community wanted and was eager to get. I still recall the time that randos crit…
The vast majority of C programmers will agree that they don't care for any of the new features, as is clearly evident by the fact that almost nobody elects to use the latest standards. The "most popular programming languages" are irrelevant here. C and C++ are standardized languages, and also the tools we use for code that actually matters. A standard that can't be implemented is worthless, and even the "3 high quali…
I think there might be some mix between "we don't want any of the new features" and "we want the new features but can't". Probably hard to get good data on the precise split.
> A standard that can't be implemented is worthless, and even the "3 high quality" implementations of C/C++ haven't fully implemented the latest 2 editions of either language.
This is a bit black-and-white. Just because a standard isn't fully implemented doesn't mean the parts that are implemented can't be useful, especially if the "haven't implemented this yet" is more due to a lack of manpower/attention/desire/etc. than actual impossibility (e.g., libc++ and parallel algorithms/ vs. export template).
Earlier quoted context omitted.
> Also span had no bounds checking While there was no reason not to have .at(), lack of bound checks by default isn't a bad thing, as inlined bound checks have the potential to highly pessimize code (esp. in loops); also standard library hardening is a thing. IMO there's much more value to be had in migrating C code (and pre-C++11 code, too) to C++ (or Rust, depending on one's tastes); RAII - that is to say, the abil…
I like how it's handled in Herb's cpp2/cppfront. If the type implements certain methods (like size()), and you turn on bounds checking, then the indexing operations (which are unsafe) are wrapped in i . This way the indexing operation itself doesn't need to have bounds checks and it's easier for the compiler to optimize out the checks or for an "unchecked" section to be requested by the programmer.
For what it's worth, something similar was proposed in the C++26 core profiles paper [0] and that particular bit got some pushback. From a reponse paper [1]:
> The paper’s suggested approach includes adding bounds checking to containers solely based on a duck-typed deduction using the availability of operators and member functions without knowing for sure what purpose the container serves, what those members do, or even whether the class is, in fact, a container at all. [P3081]’s proposal would cause a wide variety of existing, perfectly valid code to fail unpredictably at run time:
> — Containers that are not zero-indexed
> — Sparse containers
> — Map-like types the compiler cannot detect as being map-like
> — A two-color image where size() is in bytes but for which indexing is by pixel (i.e., by bit)
> — Ring-like containers
> — Containers that automatically grow.
> [P3081] also fails to consider that some library vendors already (and will continue in the future to) choose to put contract preconditions on their operator[], which would result in double and possibly inconsistent checking.
> Here unreacheable() is the new macro from C23 (and C++23) that makes the behaviour undefined whenever the branch of the invocation is reached. I cannot, in good conscience, use a technology that adds even more undefined behavior. Instead it reinforces my drive to avoid C whenever I can and use OCaml or Rust instead.