291–300 of 360 posts
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?
Personally this[1] just makes C much more complicated for me, and I choose C when I want simplicity. If I want complicated, I would just pick C++ which I typically would never want. I would just pick Go (or Elixir if I want a server). "_BitInt(N)" is also ugly, reminds me of "_Bool" which is thankfully "bool" now. [1] guard, defer, auto, constexpr, nullptr (what is wrong with NULL?), etc. On top of that "constexpr" a…
In my opinion, complexity doesn't scale linearly like this. Sometimes, in fact often times, having more complex tools means a simpler process and end result.
It's like building a house. A hammer and screwdriver are very simple. A crane is extremely complex. But which simplifies building a house? A crane. If I wanted to build a house with only a hammer and screwdriver, I would have to devise incredibly complex processes to get it done.
You see the same type of thing in programming languages. Making a generic container in C++ is trivial. It's very, very hard in C. You can make it kind of generic. You can use void * and do a bunch of manual casting. But it's cumbersome, error prone, and the code is more complex. It's counter-intuitive - how can C, a simpler language, produce code that is more complex than C++?
Or look at std::sort vs qsort. The power of templates and functors makes the implementation much simpler - and faster! We don't have to pass around void * and dereference them at runtime, instead we can build in comparison into the definition of the function itself. No redirection, no passing on the stack, and we can even go so far as to inline the comparison function.
There's really lots of examples of this kind of stuff. Point being, language complexity does not imply implementation complexity.
Earlier quoted context omitted.
Is there some end to this criticism or do you have some stake in dismissing big endian architectures?
Uh, why so serious? I called it "a bit of a stretch ;D" - there was a reason for that smiley. I'm well aware BE is alive enough to be around. If you can't live without knowing, sure, my stake in dismissing big endian architectures is that I can't in fact dismiss BE architectures because I have users on it. And it's incredibly painful to test because while my users have such hardware, actually buying a good test platf…
Fair—my bad, I can fail at reading tone sometimes.
Would you propose the C abstract machine abstracting away endianness entirely as an alternative? My understanding is that deprecating support for existing architectures is discouraged to every practical extent.
Earlier quoted context omitted.
Programmers make stupid mistakes in the safest languages too, even more so today when software is a career and not a hobby. What does it matter if the memory allocation is safe when the programmer exposes all user sessions to the internet because reading Dockers' documentation is too much work? Even Github did a variant of this with all their resources.
Because memory vulnerabilities don't make programs immune to other dumb mistakes. You get these vulnerabilities on top of everything else that can go wrong in a program. Manual checking of memory management correctness takes extra time and effort to review, debug, instrument, fuzz, etc. things that the compiler could be checking automatically and reliably. This misplaced effort wastes resources and takes focus away f…
The issue is that these great new tools don't just fix the old vulnerabilities, they also provide a lot of new, powerful footguns for people to play with. They're shipping 2000 feet of rope with every language when all we need is 6 feet to hang ourselves.
I've been using modern C++ for a personal project (a language interpreter) for the last year+. I constantly think of switching to C, because of the mental burdens of C++, and because of the problems with tooling (Visual Studio's IntelliSense still barely works, because I use C++20 modules), and compile times get ugly because of the way the language failures force so much into interfaces (even with modules). But on th…
For your particular use case, have you considered C#? VS works much more nicely with it.
Earlier quoted context omitted.
Please explain what you mean by "a separate instruction".
Some idiomatic C code to copy a string (I'm not saying this is good C code, but it's just an example): while(*d++ = *s++) ; On the Motorola 68000 (based somewhat on the PDP-11) the code would look like: loop: move.b (a0)+,d0 move.b d0,(a1)+ bne loop while on the x86 line, it would be: loop: mov al,[rsi] mov [rdi],al inc rsi ; extra instruction! inc rdi ; extra instruction! cmp al,0 jne loop Yes, there are better ways…
...
> loop: mov al,[rsi] mov [rdi],al
This hurts my brain. When we invent time machines I'm going to use it to go back and slap whoever at intel came up with that operand order.
Earlier quoted context omitted.
> IIRC Clang implements a C++ style auto, while GCC implements a C style auto, which has subtle differences for 'auto pointers' - not sure if those differences have been fixed in the meantime Both have compatibly implemented the standard C++ auto. Since 2011 or so.
Well, not in C :) Here's an example where Clang and GCC don't agree about the behaviour of auto in C23: https://www.godbolt.org/z/WchMK18vx IIRC Clang implements 'C++ semantics' for C23 auto, while GCC doesn't. Last time I brought that up it turned out that both behaviours are 'standard compliant', because the C23 standard explicitly allows such differing behaviour (it basically standardized the status quo even if di…
Did you mean gcc? Your link shows a gcc error:
:3:5: error: 'auto' requires a plain identifier, possibly with attributes, as declarator
3 | auto* p = &i;
| ^~~~Earlier quoted context omitted.
The idiomatic void strcpy(char *s, char *t) { while (*s++ = *t++) ; } (straight from K&R) wouldn’t work without it.
K&R actually teaches this as a desirable idiom? People should not be recommending K&R to beginners today!
Although this may seem cryptic at first sight, the notational convenience is considerable, and the idiom should be mastered, because you will see it frequently in C programs.
Earlier quoted context omitted.
Remember that C++ originally didn't have variadic templates, so something like std::format would have been impossible back in the day. Back in the day, std::iostream was a very neat solution for type safe string formatting. As you conceded, it also makes it very easy to integrate your own types. It was a big improvement over printf(). Historic perspective is everything.
{fmt} used to support pre-C++11 compilers that didn't have variadic templates. It was a pain to emulate variadics but it wasn't impossible.
> The storage order, the endianness, as given for my machine, is called little-endian. A system that has high-order representation digits first is called big-endian. Both orders are commonly used by modern processor types. Some processors are even able to switch between the two orders on the fly. Calling big endian "commonly used by modern processor types" when s390x is really the only one left is a bit of a stretch…
MIPS is still quite alive in consumer networking hardware.
Any recommended hardware I should use for bare metal development messing around? Hopefully priced like a SBC like the raspberry pi.
Want to move from making basic programs like adding, messing with functions, etc and bring my MIPS assembly up to a real hardware environment.