31–40 of 46 posts
https://news.ycombinator.com/item?id=40307098
> Inspired by datatype99, but consisting of one small standard-conforming C99 macro-only header that is fast to compile.
Earlier quoted context omitted.
C evolves, even if slowly. I think some devs are fed up of Complexity and excessive abstractions. C has very few language features, it's a very simple language -- while all modern languages have new (complex and taxing) features. It's kinda like a Minimalist movement, can we do the same Modern Mumbo Jumbo but in a simple, minimalistic C way? GC and RAII? Nah, just use Arenas/Pools. Or don't use heap at all. C is an u…
Anyone who thinks C is simple is just aiming the gun at their foot. If you want simple, you want something like Scheme.
Earlier quoted context omitted.
C evolves, even if slowly. I think some devs are fed up of Complexity and excessive abstractions. C has very few language features, it's a very simple language -- while all modern languages have new (complex and taxing) features. It's kinda like a Minimalist movement, can we do the same Modern Mumbo Jumbo but in a simple, minimalistic C way? GC and RAII? Nah, just use Arenas/Pools. Or don't use heap at all. C is an u…
Anyone who thinks C is simple is just aiming the gun at their foot. If you want simple, you want something like Scheme.
I know it's a minor thing, but why does this link to GitHub? The repository is described only as being a mirror of a SourceHut repo, and the user's profile has a banner telling that he's part of the giveupgithub.org movement. Looking at this post's submitter username, I think OP is the one who owns the repository, so why do this?
+1. It cannot possibly be worse than the C++ `std::variant` blunder.
Honest question: what's wrong with std::variant? I'm quite fond of using it. Sure it has trade offs like being empty by exception, but that's necessary if you don't want it to allocate. Also, pattern matching would be nice instead of std::get with visitor, but that's more of a language issue than an std::variant issue
Question: is C gaining in popularity? If so, why exactly? Are their good reasons to be using C in product development rather than more modern languages?
C evolves, even if slowly. I think some devs are fed up of Complexity and excessive abstractions. C has very few language features, it's a very simple language -- while all modern languages have new (complex and taxing) features. It's kinda like a Minimalist movement, can we do the same Modern Mumbo Jumbo but in a simple, minimalistic C way? GC and RAII? Nah, just use Arenas/Pools. Or don't use heap at all. C is an u…
This will solve more than 90% of problems. I'll also add that replace C pointers with a "Fat Pointer" or Go-like slice struct and avoid the C stdlib. Then you'll have fixed 99% of issues.
I know it's a minor thing, but why does this link to GitHub? The repository is described only as being a mirror of a SourceHut repo, and the user's profile has a banner telling that he's part of the giveupgithub.org movement. Looking at this post's submitter username, I think OP is the one who owns the repository, so why do this?
I am confused. If the author is part of the Give Up GitHub movement, then why still keep 29 repositories on GitHub! Obviously, they didn't give it up.
By relying on github for the latter while redirecting to another mirror for the former allows you to utilise github's reputational system to promote both your project AND the mirroring alternative.
Question: is C gaining in popularity? If so, why exactly? Are their good reasons to be using C in product development rather than more modern languages?
Earlier quoted context omitted.
Honest question: what's wrong with std::variant? I'm quite fond of using it. Sure it has trade offs like being empty by exception, but that's necessary if you don't want it to allocate. Also, pattern matching would be nice instead of std::get with visitor, but that's more of a language issue than an std::variant issue
> that's necessary if you don't want it to allocate. Wait, what does one have to do with the other?
valueless_by_exception happens when the move assignment operator throws (which should never happen in good C++, but is not disallowed by the language). That means, the variant used to hold value X, we were moving value Y into it, but the move assignment operator failed. What is now the state of the variant? It's not X, since we started running the move constructor, which could have started destroying the old value before throwing. But it's not Y either, because the constructor didn't finish. So what's the value that's being held? The answer is that there is no valid value.
How could this be fixed using allocation? Well, if you assume that std::variant allocated, it could be implemented in such a way that the std::variant just held a pointer to a heap area which stored the actual contents of the value. When you move assign, you construct a new element on the heap and move into that.
If the move assignment completes successfully, you swap the old value pointer for the new one and destroy the old value. But if move assignment/construction fails, you just retain the old pointer: nothing has been destroyed, and the variant still holds a valid value. This is very similar to the "strong exception guarantee" for std::vector, which is violated if the move assignment operator for the value throws.
This is one of many reasons why the move constructor/assignment operator should always be noexcept: there's no reason why it should ever throw, and it violates a bunch of these kinds of guarantees.
I think, anyway. I would be happy to be corrected if I got this wrong.