211–220 of 360 posts
Earlier quoted context omitted.
It was on purpose, Microsoft was done with C, the official message was to move on to C++. The change of heart was the new management, and the whole Microsoft <3 FOSS.
> It was on purpose, Microsoft was done with C Indeed, and yet here we are with C23 > The change of heart was the new management, and the whole Microsoft Yeah, agree. To me the turning point was when they created WSL.
Most important aspect of C is its portability. From small microcontrollers to almost any computing platform. I doubt that any new version of C will see that much adoption. If I want to live on cutting edge I would rather use C++2x or Rust rather than C. Am I missing something? What benefit this supposedly modern C offers?
One advantage of writing C code is that you don't have annoying discussions about what idiomatic code is supposed to look like, and what language subset is the right one ;) For the cutting edge I would recommend Zig btw, much less language complexity than both modern C++ and Rust. One good but less visible side effect of C23 is that it harmonizes more syntax with C++ (like ... = {} vs {0}) which makes it a bit less a…
Earlier quoted context omitted.
Right. Also it might it sound like array-to-pointer decay is forced onto the programmer. Instead, you can take the address of an array just fine without letting it decay. The type then preserves the length.
C: int foo(int a[]) { return a[5]; } int main() { int a[3]; return foo(a); } > gcc test.c > ./a.out Oops. D: int foo(int[] a) { return a[5]; } int main() { int[3] a; return foo(a); } > ./cc array.d > ./array core.exception.ArrayIndexError@array.d(1): index [5] is out of bounds for array of length 3 Ah, Nirvana! How to fix it for C: https://www.digitalmars.com/articles/C-biggest-mistake.html
int foo(int (*a)[6]) { return a[5]; }
int main() {
int a[3];
return foo(&a);
}
int foo(int n, int (*a)[n]) { return (\*a)[5]; }
int main() {
int a[3];
return foo(ARRAY_SIZE(a), &a);
}
/app/example.c:4:38: runtime error: index 5 out of bounds for
type 'int[n]'
Earlier quoted context omitted.
Or in other words, for embedded and existing code: most use c99, some use c11 and nobody uses c23 until at least 10 years from now.
This depends on the platform. Many embedded systems are based on arm these days and have modern toolchains available. I cannot remember the last time I saw C99 used. C codebases generally use C11 or C17, and C++ code bases use C++20
Also 8 and 16 bit embedded toolchains are certainly not on C11 / C17, they can hardly afford full C89.
any chance of getting a responsive TOC in any pdf reader whatsoever?
Earlier quoted context omitted.
Nice, when you know the length at compile time, which is rarely from my experience. The holy grail is runtime access to the length, which means an array would have to be backed by something more elaborate.
Oh, it also work for runtime length: https://godbolt.org/z/PnaWWcK9o
Continuing to use a memory-unsafe language that has no recourse for safety and is full of footguns and is frankly irresponsible for the software profession. God help us all. By the way, the US government did the profession no favors by including C++ as a memory-unsafe language. It is possible to write memory-safe C++, safe array dereferencing C++. But it’s not obvious how to do it. Herb Sutter is working on it with C…
I see comments like yours everywhere all the time and I seriously think you have a very unhealthy emotional relationship with this topic. You should not have that much hate in your heart for a programming language that has served us very well for many decades and still continues to do so. Even if C was literally all bad (which imho isn't even possible), you shouldn't be that angry at it.
Earlier quoted context omitted.
int a; cin >> a; Then the program goes berserk as soon as the first non-number is read out of standard input. All the other "cin >> integer" lines are immediately skipped. Yes, I know about error checking, clearing error condition, discarding characters. But it's a whole lot of stuff you need to do after every single "cin>>" line. It makes the simplicity of cin not worth it.
fscanf (STDIN, "%d", &a); the program goes beserk as soon as the first non-number is read out of standard input. in both cases, you need error checking (which you "know about").
It's more code, sure, but it buys you a lot of good things. I/O is hard.