No post body was provided.
The Problem with C (2020)
121–130 of 177 posts
Re: The Problem with C (2020)
#122Earlier quoted context omitted.
It can run in-proc and fits the scenarios being given on previous comment. I remeber Bonobo, DCOP and KPart days, so I know pretty well what D-Bus is capable of. In micro-kernels the IPC infrastructure is the userspace ABI, as it is the only way to call into OS services, beyond the little glue library to make it possible to do so.
Where did you see in-proc D-Bus? It would be wildly inefficient compared to COM/gobject anyway.
COM nowadays runs mostly out of process unless you like crashing the whole application, hence the reference to nano-COM for in-proc APIs that are basically OO ABI.
That is why any modern Windows has plenty of COM Surrougate processes running at any given time.
As for D-BUS, I stand corrected, I though it had such optimization in place, just as other mechanisms offer.
Re: The Problem with C (2020)
#123Most programming languages are really good. People who talk ill of them just don't know them well, and also probably never lived while there were no high-level languages. And honestly, people are creatures of trends; we don't use the most popular languages because they're flawless. The only major problem with C is its community never took off with a popular library packager and linter. Every other language that seems…
The C package manager was and still is (largely) any UNIX/Linux distribution and the source packages for them. That’s how common C is. Linters are up to the user. There are many, but older UNIX systems that I’ve used generally included a `lint` command. If you really wanted to, you could consider UNIX/Linux operating systems the “IDE” and package manager for C.
Re: The Problem with C (2020)
#124Earlier quoted context omitted.
> I don't understand why this is a C problem Because it isn't a C problem. C has been basically stable for decades. C++ is free to overload itself by piling ever more stuff onto itself, but any problems this language has, are not problems of C, or problems C needs to fix.
ISO C11, ISO C17, ISO C23, GCC C, clang C, xlc, aC, TICC, MSVC C, ...
> ISO C11, ISO C17, ISO C23,
> GCC C, clang C, xlc, aC, TICC, MSVC C
Absolutely. Some are feature fixes, malloc changes etc. How many of them are breaking changes or deprecations?
Re: The Problem with C (2020)
#125Earlier quoted context omitted.
ISO C11, ISO C17, ISO C23, GCC C, clang C, xlc, aC, TICC, MSVC C, ...
> ISO C11, ISO C17, ISO C23, > GCC C, clang C, xlc, aC, TICC, MSVC C Absolutely. Some are feature fixes, malloc changes etc. How many of them are breaking changes or deprecations?
C11 made a couple of breaking changes, any compiler is no longer required to support the optional annexes.
Your beautiful VLAs will stop working, unless one only uses GCC or clang forks.
Re: The Problem with C (2020)
#126Earlier quoted context omitted.
The best way to put it for modern generations is that C++ was "TypeScript" for C, with all the plus and minus that it entails.
The comparison is flawed, because Javascript is a subset of Typescript, but C is not a subset of C++. A better analogy would be that C++ is to C what Dart is to Javascript.
It was when C++ came to be, 40 years ago.
Don't mix stuff with how things are today.
Re: The Problem with C (2020)
#127C 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. I liked C in the 80s, 90s and 2000s. It was a neat and simple language, but that changed as compilers got more aggressive with their optimizations and exposed just how complicated and unintuitive the spec actually is (and the impossibility of avoidi…
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.
Re: The Problem with C (2020)
#128Earlier quoted context omitted.
I think it would be beneficial to create a better interoperable ABI description (one, not a dozen). Not in a form of a language header, but a data file that can be easily consumed by tools of any non-C language. 1. C headers are exceptionally annoying to correctly parse and interpret. You basically have to have a full C compiler, which is a PITA for a non-C tool. It's not just complexity of the C syntax, but dependen…
Could WASI grow into this role?
WASI is an API, not a way of specifying APIs.
Re: The Problem with C (2020)
#129Earlier quoted context omitted.
It's not a particular operation that is the problem, it's writing a whole real-life program with no UB that is the problem. Even so, one example in C++ where it's almost impossible to avoid UB is treating a piece of memory as both a struct and raw bytes with guarantees of no copying. This comes up a lot in network packet processing.
This makes me wonder how protobufs manages to implement zero-copy structs.
I bet they use UB in more than one place. It's just some instance of UB that compilers aren't exploiting with crazy interpretations that lead to faster non-working programs.
The people saying that it's technically possible to create that code without UB say that with a certainty that isn't viable. You don't need to just read the standard from beginning to end to determine if your code has UB, you need to also remember it all. Some part of it not applying to your case doesn't stop the UB on that part from appearing in your code, and there isn't a usable list of UB you can quickly check against (the closest that exists is the set of UB that compilers are using on their crazy extrapolations, what is not the same thing).
There is just no way to know that you avoided it all.
Re: The Problem with C (2020)
#130If 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.