5 ms·

This is why I love the simplicity of C (C99 in particular). I remember back when I started learning C++, after years of experience writing C, I was admittedly t

This is why I love the simplicity of C (C99 in particular). I remember back when I started learning C++, after years of experience writing C, I was admittedly turned on by the cool features like smart pointers, standard data structures, etc., but once I read/wrote any significant amount of C++ code, the “deceptively simple” code quickly turned me off and had me running back to C. Suddenly, nothing was what it seemed. With C, I could jump into a codebase, and within a few hours/days, I’d have decent enough understanding of what’s going on, whereas C++ had me constantly wondering . . . - If certain operators were being overloaded - How memory was being allocated in different sections, libraries, etc. - The different semantics of the various ways you can do the same thing (e.g., constructors) . . . the list goes on and on and on. I’m not trying to crap on C++, but for a low-level language, the simplicity of C is simply unmatched!

kllrnohj 4y ago
Other than operator overloads, you have all those same problems with C. Only with the extra "benefit" that the compiler won't help you with jack shit. C is not a simple language. You're either naive or lying to yourself if you think it is. But in this case C isn't even any different, so this tangent is irrelevant anyway. If you take a struct by value in C it, drum roll, copies it!
- jay-barronville 4y ago
  Sorry, I beg to differ. C is a simple language. The overwhelming majority of issues I’ve encountered writing C code haven’t had anything to do with the language; most issues have turned out to be due to compiler, library, architecture, kernel, OS, etc.-related differences, peculiarities, and/or issues. C++, on the other hand, makes it incredibly easy to shoot yourself in the foot at the language level.
  - rightbyte 4y ago
    > Sorry, I beg to differ. C is a simple language. The problem with C is that it so simple that it is simple to complain about it. Other languages hide their quirks deeper down and are harder to complain about.
- jay-barronville 4y ago
  > But in this case C isn't even any different, so this tangent is irrelevant anyway. If you take a struct by value in C it, drum roll, copies it! You’re absolutely correct, but I also don’t have to worry about copy versus move semantics and all that other jazz in C — the mental model is simply value copies or pointer copies, that’s it.
  - kadoban 4y ago
    By the time you actually add enough libraries to be able to get something done, you have to worry about the same concepts, the names are just different and it's less consistent since the language doesn't help or have a position on how it works. C is a simple language the same way my car is simple if I take the engine out.
    - jay-barronville 4y ago
      What a false equivalence. I don’t understand the need to pretend like C++ isn’t a minefield of complexity (especially compared to C). I don’t hate the language and C++ programmers tend to be some of the smartest programmers I know/encounter, but can we please not be deliberately obtuse here?
      - kllrnohj 4y ago
        C is a minefield of complexity, though, why are you so desperate to pretend it isn't? The reality is that much of the language complexity of things like C++ or Rust is because the problem space is actually complex. C's language just doesn't help you with the inherent complexity. In fact it actively encourages bugs as a result. That's not a simple language, it's a bad one. It was fine for the constraints of the time, but it's not anymore. C is easily the least defensible language choice of the commonly used languages. There's so many just obscenely better options it's not even funny. See also why even "intentionally C-like" languages like Zig are growing increasing complexity https://github.com/ziglang/zig/issues/7769 https://github.com/ziglang/zig/issues/7769 Or why things like D's betterC adds all the same "objectionable" stuff C++ does - RAII, operator overloading, etc...
- _gabe_ 4y ago
  > C is not a simple language In comparison to C++ it is. C++ isn't a strict superset of C, but for all intents and purposes, it supports all the nasty warts of C PLUS a million other foot guns added on with no guidance whatsoever on which features are "safe" and "modern". Just a short list of additional complexities in C++: constructors/destructors, operator overloading, templates, constexpr/consteval, copy constructors/move constructors/perfect forwarding etc, smart pointers (when do you use smart versus raw? Herb Stutter has some guidelines on this), lambdas, massive std lib, etc. > But in this case C isn't even any different, so this tangent is irrelevant anyway. But C is different... if you pass by value in C what's going to happen? It copies the bits. What about C++? Drum roll please... Who the heck knows. It could call some copy constructor, or it could just copy the bits, or it could recursively call copy constructors on all the nested objects etc. You literally cannot tell in C++ without looking at the implementation or already knowing what's going to happen.
  - kllrnohj 4y ago
    You're right, of course. In C I don't even know if the code works at all, whereas I can be reasonably confident it does in C++. But hey, it's apparently more important to know it's a memcpy than to know it works! Such simplicity! I'm so glad a built-in operator has just no expectations of being useful or correct, what a truly wonderful language.
    - _gabe_ 4y ago
      You're shifting the goalpost here. You said: > C is not a simple language In response to the claim that: > I’m not trying to crap on C++, but for a low-level language, the simplicity of C is simply unmatched! C is simpler than C++, for the reasons I outlined above. This has no correlation on how correct the code is or if it works. If you want to argue that, go ahead but that's a different argument. > But hey, it's apparently more important to know it's a memcpy than to know it works! Such simplicity! I'm so glad a built-in operator has just no expectations of being useful or correct, what a truly wonderful language. Great, you can be facetious all you want, it doesn't add or detract to your claim that C is not simple in comparison to C++. And by the way, I use C++ and prefer it to C. I love the fact that you can use templates in C++ for type safety when it comes to generic containers and use destructors to help with resource management etc. But let's not kid ourselves, C is simpler than C++ and trying to argue against that is pointless.
- jennyyyyy 4y ago
  >But in this case C isn't even any different, so this tangent is irrelevant anyway. If you take a struct by value in C it, drum roll, copies it! Not quite, in C you know that the most that can happen is a memcpy() call (or some form of inlined byte/word copy) whereas in C++ a copy constructor can do anything - like allocating memory, which might fail and raise an exception.
  - kllrnohj 4y ago
    In C I don't even have a clue if the copy is even valid at all or if I was supposed to call some bespoke function or use some wacky macro somewhere. C++ is a strict improvement in that you can at least generally assume the assignment operator produces functional code if it compiles, and types with unusually expensive assignments can opt to prevent the assignment operator from being used at all to make that clear.
- jstimpfle 4y ago
  > Other than operator overloads, you have all those same problems with C. How about no? RAII and exceptions do a lot of stuff that is hard to see (because most of the time, there literally isn't any written code that calls them).
  - josefx 4y ago
    > (because most of the time, there literally isn't any written code that calls them). RAII code wont be invoked unless you literally declare an object in the function. You might as well complain that C implicitly reserves space on the stack for variables despite the fact that you did not explicitly call alloca to do it.
    - jstimpfle 4y ago
      Well, operator overloads won't be invoked unless you literally write the operators. They can be surprising nevertheless, as the commenter above rightfully expressed. And RAII/constructors/destructors can be surprising and annoying, too. It means buying into a framework, giving up control. This can be a good thing, but it can be hard to control, and be hard to debug, too. alloca() vs stack variables is something different, it's dynamic vs static allocation. You can literally see (ignoring optimization to make this point) all the stack variables that are part of the stack frame. It's in plain sight, very explicit and obvious to the eye. While calls to operator overloads and ctors/dtors are not visible in the plain syntax (type resolution is needed), and in case of virtual methods they might not even be resolved until runtime. So please don't make me angry, this was a really weak refutal. Statements like this are why I am sometimes more critical at C++ than it maybe deserves.
      - josefx 4y ago
        > It means buying into a framework, giving up control The fun part is that you can still use plain old objects if you really really want to deal with C-Strings. > It's in plain sight, very explicit and obvious to the eye. And since RAII applies to variables the same is true in c++, unless you pretend to write C. > and in case of virtual methods they might not even be resolved until runtime. Except the type of a stack allocated object is known at compile time and ctors and dtors are part of that type. For operators you can also generally see from the type if they are overloaded and possibly virtual even if you are not dealing with directly stack allocated objects.

kllrnohj 4y ago

Other than operator overloads, you have all those same problems with C. Only with the extra "benefit" that the compiler won't help you with jack shit. C is not a simple language. You're either naive or lying to yourself if you think it is. But in this case C isn't even any different, so this tangent is irrelevant anyway. If you take a struct by value in C it, drum roll, copies it!

jay-barronville 4y ago
Sorry, I beg to differ. C is a simple language. The overwhelming majority of issues I’ve encountered writing C code haven’t had anything to do with the language; most issues have turned out to be due to compiler, library, architecture, kernel, OS, etc.-related differences, peculiarities, and/or issues. C++, on the other hand, makes it incredibly easy to shoot yourself in the foot at the language level.
- rightbyte 4y ago
  > Sorry, I beg to differ. C is a simple language. The problem with C is that it so simple that it is simple to complain about it. Other languages hide their quirks deeper down and are harder to complain about.
jay-barronville 4y ago
> But in this case C isn't even any different, so this tangent is irrelevant anyway. If you take a struct by value in C it, drum roll, copies it! You’re absolutely correct, but I also don’t have to worry about copy versus move semantics and all that other jazz in C — the mental model is simply value copies or pointer copies, that’s it.
- kadoban 4y ago
  By the time you actually add enough libraries to be able to get something done, you have to worry about the same concepts, the names are just different and it's less consistent since the language doesn't help or have a position on how it works. C is a simple language the same way my car is simple if I take the engine out.
  - jay-barronville 4y ago
    What a false equivalence. I don’t understand the need to pretend like C++ isn’t a minefield of complexity (especially compared to C). I don’t hate the language and C++ programmers tend to be some of the smartest programmers I know/encounter, but can we please not be deliberately obtuse here?
    - kllrnohj 4y ago
      C is a minefield of complexity, though, why are you so desperate to pretend it isn't? The reality is that much of the language complexity of things like C++ or Rust is because the problem space is actually complex. C's language just doesn't help you with the inherent complexity. In fact it actively encourages bugs as a result. That's not a simple language, it's a bad one. It was fine for the constraints of the time, but it's not anymore. C is easily the least defensible language choice of the commonly used languages. There's so many just obscenely better options it's not even funny. See also why even "intentionally C-like" languages like Zig are growing increasing complexity https://github.com/ziglang/zig/issues/7769 https://github.com/ziglang/zig/issues/7769 Or why things like D's betterC adds all the same "objectionable" stuff C++ does - RAII, operator overloading, etc...
_gabe_ 4y ago
> C is not a simple language In comparison to C++ it is. C++ isn't a strict superset of C, but for all intents and purposes, it supports all the nasty warts of C PLUS a million other foot guns added on with no guidance whatsoever on which features are "safe" and "modern". Just a short list of additional complexities in C++: constructors/destructors, operator overloading, templates, constexpr/consteval, copy constructors/move constructors/perfect forwarding etc, smart pointers (when do you use smart versus raw? Herb Stutter has some guidelines on this), lambdas, massive std lib, etc. > But in this case C isn't even any different, so this tangent is irrelevant anyway. But C is different... if you pass by value in C what's going to happen? It copies the bits. What about C++? Drum roll please... Who the heck knows. It could call some copy constructor, or it could just copy the bits, or it could recursively call copy constructors on all the nested objects etc. You literally cannot tell in C++ without looking at the implementation or already knowing what's going to happen.
- kllrnohj 4y ago
  You're right, of course. In C I don't even know if the code works at all, whereas I can be reasonably confident it does in C++. But hey, it's apparently more important to know it's a memcpy than to know it works! Such simplicity! I'm so glad a built-in operator has just no expectations of being useful or correct, what a truly wonderful language.
  - _gabe_ 4y ago
    You're shifting the goalpost here. You said: > C is not a simple language In response to the claim that: > I’m not trying to crap on C++, but for a low-level language, the simplicity of C is simply unmatched! C is simpler than C++, for the reasons I outlined above. This has no correlation on how correct the code is or if it works. If you want to argue that, go ahead but that's a different argument. > But hey, it's apparently more important to know it's a memcpy than to know it works! Such simplicity! I'm so glad a built-in operator has just no expectations of being useful or correct, what a truly wonderful language. Great, you can be facetious all you want, it doesn't add or detract to your claim that C is not simple in comparison to C++. And by the way, I use C++ and prefer it to C. I love the fact that you can use templates in C++ for type safety when it comes to generic containers and use destructors to help with resource management etc. But let's not kid ourselves, C is simpler than C++ and trying to argue against that is pointless.
jennyyyyy 4y ago
>But in this case C isn't even any different, so this tangent is irrelevant anyway. If you take a struct by value in C it, drum roll, copies it! Not quite, in C you know that the most that can happen is a memcpy() call (or some form of inlined byte/word copy) whereas in C++ a copy constructor can do anything - like allocating memory, which might fail and raise an exception.
- kllrnohj 4y ago
  In C I don't even have a clue if the copy is even valid at all or if I was supposed to call some bespoke function or use some wacky macro somewhere. C++ is a strict improvement in that you can at least generally assume the assignment operator produces functional code if it compiles, and types with unusually expensive assignments can opt to prevent the assignment operator from being used at all to make that clear.
jstimpfle 4y ago
> Other than operator overloads, you have all those same problems with C. How about no? RAII and exceptions do a lot of stuff that is hard to see (because most of the time, there literally isn't any written code that calls them).
- josefx 4y ago
  > (because most of the time, there literally isn't any written code that calls them). RAII code wont be invoked unless you literally declare an object in the function. You might as well complain that C implicitly reserves space on the stack for variables despite the fact that you did not explicitly call alloca to do it.
  - jstimpfle 4y ago
    Well, operator overloads won't be invoked unless you literally write the operators. They can be surprising nevertheless, as the commenter above rightfully expressed. And RAII/constructors/destructors can be surprising and annoying, too. It means buying into a framework, giving up control. This can be a good thing, but it can be hard to control, and be hard to debug, too. alloca() vs stack variables is something different, it's dynamic vs static allocation. You can literally see (ignoring optimization to make this point) all the stack variables that are part of the stack frame. It's in plain sight, very explicit and obvious to the eye. While calls to operator overloads and ctors/dtors are not visible in the plain syntax (type resolution is needed), and in case of virtual methods they might not even be resolved until runtime. So please don't make me angry, this was a really weak refutal. Statements like this are why I am sometimes more critical at C++ than it maybe deserves.
    - josefx 4y ago
      > It means buying into a framework, giving up control The fun part is that you can still use plain old objects if you really really want to deal with C-Strings. > It's in plain sight, very explicit and obvious to the eye. And since RAII applies to variables the same is true in c++, unless you pretend to write C. > and in case of virtual methods they might not even be resolved until runtime. Except the type of a stack allocated object is known at compile time and ctors and dtors are part of that type. For operators you can also generally see from the type if they are overloaded and possibly virtual even if you are not dealing with directly stack allocated objects.