[array_key_first]

The idea that people occasionally throw around that C is more 'simple' and less 'complex' than C++ or Rust and therefore it leads to more maintainable or easy to understand code is, IMO, completely bogus.

C is not simple, it is inept. There are so, so many bargain-bin features and capabilities that it just cannot do that it ends up creating much MORE complex code, not less complex code.

I mean, just the pretense that simple tool = simple engineering isn't necessarily true. Building a home using an excavator and drills is fairly straight forward. You know what's complicated? Trying to build a home using only a screwdriver. Yeah. Good luck with that, you're gonna have to come up with some truly insane processes to make that work. Despite a screwdriver being so much more simple than an excavator.

Trivial example: you want to build a container that can hold data of different types and perform generic operations on them.

C++ and Rust? Easy. Templates and generics. C? Up until a few years ago, your options were: 1. copy and paste (awful) or 2. use void * (also awful).

Copy and paste means your implementations will diverge and you just artificially multiplied your maintenance burden and complexity. And void pointer completely throws away any semblance of type safety, forces you to write stupid code that's way more complex than it needs to be, and, to top it off, is horrible for performance!

That's just one example, but there's so, so many when you look around C++ or Rust enough. And these are not rare things, to me. To me, these are everyday coding problems.

Anonymous functions? There's another one. Encapsulation? Just making not literally every piece of data universally mutable? Not possible in C. Trivial in C++ and Rust, and it makes your programs SO much easier to reason about.

[pdpi]

> Just making not literally every piece of data universally mutable? Not possible in C. Trivial in C++ and Rust, and it makes your programs SO much easier to reason about.

And Rust is significantly better at this than C++ for the simple reason that mut is a modifier. I’ve lost track of how many times I’ve listened to Kate Gregory extol the virtues of const-ing all the things, but people still don’t systematically add it, and, as readers, we’re left wondering whether things actually need to be mutable, or the author forgot/didn’t know to add const-ness to their code. With Rust having opt-in mutability, you know for a fact that mutability was a deliberate choice (even if sometimes the only motivation was “make the compiler happy”).

[TuxSH]

> I’ve lost track of how many times I’ve listened to Kate Gregory extol the virtues of const-ing all the things, but people still don’t systematically add it

Adding const to _function-local_ variables only really matters when you "leak" a pointer or ref, whether mutable or const, to a function or variable the compiler can't optimize away:

    std::size_t sz = 4096;
    const std::size_t &szRef = sz;
    some_opaque_func(szRef);
    if (sz != 4096) std::abort(); // cannot be optimized away unless sz is const

as there is no way to know if something obtains a mutable ref to sz down the line.

In other cases like RVO, adding const is actually detrimental as it prevents the move-constructor from being selected (likewise with the move assignment operator).

Rust _needs_ to have const by default due to its aliasing model ("only one mutable ref per object") and you can't have cheap bound checks without this. But that, too, is a tradeoff (some classes of programs are hard to code in Rust)

[aw1621107]

Pretty sure the std::abort() can't be optimized away if sz is mutable since it's legal for some_opaque_func() to cast away szRef's const and modify sz via that. sz itself needs to be const for the if statement to be removable as dead code.

https://cpp.godbolt.org/z/Pa3bMh9Ee shows that both GCC and Clang keep the abort when sz is not const. Add const and the abort goes away.

[TuxSH]

Yes, that is what I said - sorry if this wasn't clear

[aw1621107]

Looking back I think I might have misread your comment and thought you meant that the const on the reference was what mattered. Sorry about that!

[baq]

> The idea that people occasionally throw around that C is more 'simple' and less 'complex' than C++ or Rust and therefore it leads to more maintainable or easy to understand code is, IMO, completely bogus.

This, this, this.

C compilers are simple, but the C language is not, and let’s not even talk about C++.

[oconnor663]

I like to focus on the ways that C is actually quite complicated, especially the complications that directly provoke UB when you don't know about them. Integer promotion and strict aliasing are at the top of my list.

[justjulia]

>Trivial example: you want to build a container that can hold data of different types and perform generic operations on them.

Do I?

I would simplify the problem to not need different types or generic operations.

Or if I really need generic operations, break them down to smaller operations so you don't need to take a bunch of type parameters everywhere.

For example containers, instead of having container<T>, have the container operations return an index or 'opcode', then the user applies that to their data. The container doesn't need to know about T, void pointers or sizes, just its own internal bookkeeping stuff.

[simonask]

That's valid, even sensible, but you have now left significant performance on the table.