How does "Modern" C compare safety-wise to Rust or Zig?
The C23 edition of Modern C
41–50 of 360 posts
Re: The C23 edition of Modern C
#42Earlier quoted context omitted.
Bjarne should have called it ++C.
Because people choose to use pre-increment by default instead of post-increment? Why is that?
It should be ++C because with C++ the value you get from the expression is the old one.
If you're asking why people use pre-increment by default instead of post-increment, it's mostly historical. The early C compilers on resource-constrained platforms such as early DOS were not good at optimization; on those, pre-increment would be reliably translated to a simple ADD or INC, whereas code for post-increment might generate an extra copy even if it wasn't actually used.
For C++ this was even worse with iterators, because now it depended on the compiler's ability to inline its implementation of postfix ++, and then prove that all the copies produced by that implementation have no side effects to optimize it to the same degree as prefix ++ could. Depending on the type of the underlying value, this may not even be possible in general.
The other reason is that all other unary operators in C are prefix rather than postfix, and mixing unary prefix with unary postfix in a single expression produces code that is easy to misunderstand. E.g. *p++ is *(p++), not (*p)++, even though the latter feels more natural, reading it left-to-right as usual. OTOH *++p vs ++*p is unambiguous.
Re: The C23 edition of Modern C
#43Earlier quoted context omitted.
Specially relevant to all those folks that insist on "Coding C with a C++ compiler", instead of safer language constructs, and standard library alternatives provided by C++ during the last decades.
Funny because for a long time the Microsoft MSVC team explicitly recommended compiling C code with a C++ compiler because they couldn't be arsed to update their C frontend for over two decades (which thankfully has changed now) ;) https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an...
That thing always baffled me, this huge company building a professional IDE couldn't figure out how to ship updates to the C compiler.
> it is hard to say no to you, and I’m sorry to say it. But we have to choose a focus, and our focus is to implement (the standard) and innovate (with extensions like everyone but which we also contribute for potential standardization) in C++.
I mean, yeah if it came from a two member team at a startup, sure focus on C++, understandably. But Microsoft, what happened to "Developers! Developers! Developers!"?
Re: The C23 edition of Modern C
#44Earlier quoted context omitted.
On a high level, "object orientation" means you think of your code as representing the state and interactions of objects. You can equally well do this in assembly. If you think of some namespace as a "singleton object" then that's what it is. I guess what you're really asking is what are the best or most common ways to do OO in C?
Oh. I learned that object orientation is primarily a way to structure data and code, such that the data is encapsulated with the code that works on it, in so called objects. So an Object is the Data, plus the functions that work on the data, an ensure that some invariants are kept. In OO parlance, that code gets executed by sending messages (calling methods). Where can I find something about objects being "think of y…
> Where can I find something about objects being "think of your code as representing the state and interactions of objects" honesty totally new to me.
I’m scratching my head how you think this is materially different than what you described in your first para. s/state/data and s/interactions/methods.
If anything though I would say the GP is more aligned with the classic definition as it highlights the focus is more on the messages (interactions) themselves rather than the implementation.
Re: The C23 edition of Modern C
#45Important reminder just in the Preface :-) Takeaway #1: "C and C++ are different: don’t mix them, and don’t mix them up"
>Takeaway #1: "C and C++ are different: don’t mix them, and don’t mix them up"
Where "mixing C/C++" is helpful:
- I "mix C in with my C++" projects because "sqlite3.c" and ffmpeg source code is written C. C++ was designed to interoperate with C code. C++ code can seamlessly add #include "sqlite3.h" unchanged.
- For my own code, I take advantage of "C++ being _mostly_ a superset of C" such as using old-style C printf in C++ instead of newer C++ cout.
Where the "C is a totally different language from C++" perspective is helpful:
- knowing that compilers can compile code in "C" or "C++" mode which has ramifications for name mangling which leads to "LINK unresolved symbol" errors.
- knowing that C99 C23 has many exceptions to "C++ is a superset of C" : https://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B...
Re: The C23 edition of Modern C
#46Earlier quoted context omitted.
Why would you use post increment by default? The semantics are very particular. Only on very rare occasions I need post increment semantics. And in those cases I prefer to use a temporary to make the intent more clear
People seem to mostly write a typical for loop ending with ; ++i){ But I write ; i++){ and seeing it the other way round throws me off for a minute, because I think, as you put it, why would you use those very particular semantics? But I guess this is only a semantic argument.
> why would you use those very particular semantics?
The difference is that i++ has to keep a copy to the original around as the return value is the pre-increment value, while with ++i that isn't needed as the resulting value is being returned.
In the for loop that shouldn't matter as a) for an integer it is essentially for free (it is just reordering when the relevant register is set) and b) that value is hopefully optimized out anyways by the compiler, however as there are cases where it matters some people prefer the ++i style, some just think it looks better.
Re: The C23 edition of Modern C
#47Earlier quoted context omitted.
Because people choose to use pre-increment by default instead of post-increment? Why is that?
It should be ++C because with C++ the value you get from the expression is the old one. If you're asking why people use pre-increment by default instead of post-increment, it's mostly historical. The early C compilers on resource-constrained platforms such as early DOS were not good at optimization; on those, pre-increment would be reliably translated to a simple ADD or INC, whereas code for post-increment might gene…
K&R seems to use pre-increment early on, then post-increment consistently (or a lot, anyway, I haven't done a thorough check) after chapter 3, in situations where either would do. In fact, after introducing post-increment at 2.8.
Re: The C23 edition of Modern C
#48Do they still use 0-terminated strings/char* as the main string type?
Is the usage of single linked lists still prevalent as the main container type?
Re: The C23 edition of Modern C
#49Earlier quoted context omitted.
Perfectly valid to do if you need to interface with a large C code base and you just want to do some simple OO here and there. Especially if you cannot have runtime exceptions and the like. This is how I managed to sneak C++ into an embedded C codebase. We even created some templates for data structures that supported static allocation at compile time.
What would be an example of "simple OO here and there" that cannot be done cleanly in plain C?
[deleted]
Re: The C23 edition of Modern C
#50Earlier quoted context omitted.
Funny because for a long time the Microsoft MSVC team explicitly recommended compiling C code with a C++ compiler because they couldn't be arsed to update their C frontend for over two decades (which thankfully has changed now) ;) https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an...
That thing always baffled me, this huge company building a professional IDE couldn't figure out how to ship updates to the C compiler. > it is hard to say no to you, and I’m sorry to say it. But we have to choose a focus, and our focus is to implement (the standard) and innovate (with extensions like everyone but which we also contribute for potential standardization) in C++. I mean, yeah if it came from a two member…
It's not baffling, it's remarkably consistent. They implemented Java as J++ and made their version incompatible in various ways with the standard so it was harder to port your code away from J++ (and later J#). They implemented things in the CSS spec almost exactly opposite the specification to lock people into IE (the dominant browser, if you have to make your site work with 2+ incompatible systems which will you focus on?). Not supporting C effectively with their tools pushed developers towards their C++ implementation, creating more lock-in opportunities.