151–160 of 177 posts
Specifically the somewhat recent idea that code which does something naughty is best deleted. This makes updating a compiler a hazardous activity for approximately all 'C' code. Also makes refactors somewhat risky when they send code down different paths in the compiler.
I wonder if this judgement and execution result from collaboration with C++.
I dislike C++ for the same reason I dislike all languages that try to be everything. You can use the language for years and there are still parts of it that you don't understand properly. C on the other hand has such a minimal and clear syntax that you can learn it pretty fast and feel confident about the language.
Well, one of the problems of C is that it's not as simple as it wants you to think it is. :-)
> [C++] also had type inference very early on, but the developers of the mid-80s were not quite ready for that and Bjarne Stroustrup was pressured into removing auto, until it was added back to C++11. Does anybody have background information on this claim? Was there actually a working compiler with it back then or was it just some proposal paper at the time?
C is just perfect as it is.
I write a lot of code in a C++ codebase and I'd say C++ is horrific. Not just because of its roots in C, no I think it is actually a worse language than C. Notable detriments in the language include references, classes, a lot of template stuff (some of it is ok, but it makes separate compilation almost impossible).
Maybe it's just me, but I can no longer live without those.
Earlier quoted context omitted.
We've been here before with other aspects of human behaviour. If you really don't want people to do it, make it impossible and then they can't. You can't write an integer overflow in WUFFS because that doesn't compile. You can't use your Google.com WebAuthn credentials to sign into fakegoogle.example, even if you really, really want to, even if you're 100% sure this is a good idea, it can't be done. Any time you stop…
Agreed, the only way to enforce something is to make part of the type system, and that is how we land on C folks complaining about straightjacket programming languages.
Earlier quoted context omitted.
> C is the glue interface that connects all the different languages together. I wouldn't want to see anything new added to the language that complicates this lingua franca. Indeed, this is one of the two things where C is still king, the other being running on weird hardware with specialized compilers. That said, C is not a great glue language: - Zero terminated strings are only used in C so every other language need…
> Zero terminated strings are only used in C so every other language needs to do a copy to pass a string to C, even C++ (for string_view at least). This is one of the most frequent complaints and I find it ridiculous. C has string literals that encode zero-terminated strings, but you don't have to rely on these zero terminators. There are a few awquard "string functions" in libc, most of which you should just ignore.…
Just a quick question. Is there somewhat up-to-date guide, list, book, whatever of good best practices for C, or maybe small libs for simple string handling, and common pitfalls (checking for over/underflows etc.)?
If I'm writing C++, I am doing it because I need nanosecond latency (and the delicious language libraries). If I only need microsecond latency, I would use Golang. If millisecond is fine, it'd be Python in a hot minute. If I only need (as is 99% of the time the case) a smidge of code to run nanosecond-fast, I'd write a C extension and call it from a higher-level language that does the orchestration code. The C extens…
>Only in the rare case that a large program needs to be nanosecond-fast would I even consider C++ (and I'd push really hard to learn if that really needed to be true!) This is mostly true for web development where bottlenecks just exist in IO and beyond. For gaming this is not the case. The entire industry needs nanosecond latency so engines must be written in languages that are nanosecond-fast.
Earlier quoted context omitted.
I'm still a proponent of C as portable assembly, and any sort of optimizations / UB that gets used resulting in warning messages that can improve the source code of the program rather than the one time artifacts the compiler produces.
There were a couple articles about C-- here recently, I guess that language would be interesting to you.