←back to thread

The C23 edition of Modern C

(gustedt.wordpress.com)
515 points bwidlar | 3 comments | 15 Oct 24 16:06 UTC | HN request time: 2.595s | source
Show context
belter ◴[15 Oct 24 17:30 UTC] No.41850897[source]▶
Important reminder just in the Preface :-)

Takeaway #1: "C and C++ are different: don’t mix them, and don’t mix them up"

replies(8): >>41850960 #>>41851047 #>>41851166 #>>41851693 #>>41853183 #>>41855660 #>>41857019 #>>41858537 #
pjmlp ◴[15 Oct 24 17:35 UTC] No.41850960[source]▶
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.
replies(3): >>41851031 #>>41851082 #>>41851268 #
com2kid ◴[15 Oct 24 17:48 UTC] No.41851082[source]▶
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.

replies(2): >>41851140 #>>41852515 #
f1shy ◴[15 Oct 24 17:53 UTC] No.41851140[source]▶
What would be an example of "simple OO here and there" that cannot be done cleanly in plain C?
replies(6): >>41851225 #>>41851244 #>>41851407 #>>41851799 #>>41851998 #>>41854294 #
adamrezich ◴[15 Oct 24 18:02 UTC] No.41851244[source]▶
Namespaces, methods.
replies(1): >>41851261 #
f1shy ◴[15 Oct 24 18:04 UTC] No.41851261[source]▶
Namespaces is not object orientation, is it? Am I missing something? You can place functions (methods) inside of structs in C23, can't you?
replies(3): >>41851286 #>>41851339 #>>41851481 #
staunton ◴[15 Oct 24 18:06 UTC] No.41851286[source]▶
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?

replies(1): >>41851403 #
1. f1shy ◴[15 Oct 24 18:14 UTC] No.41851403[source]▶
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 your code as representing the state and interactions of objects" honesty totally new to me.

So no, certainly I'm not asking ways to do OO in C. But it seems to be more definitions of object orientation as I thought...

replies(2): >>41851523 #>>41851677 #
2. int_19h ◴[15 Oct 24 18:24 UTC] No.41851523[source]▶
There's no clear definition of what OO is, so the best you can do pragmatically is look at mainstream languages that are broadly recognized as OO and try to deduce the commonalities.

If you do that, you'll notice that, for example, encapsulation is not a part of that de facto definition, because languages like Python and (until recently) JavaScript lack it, despite being considered OO.

Indeed, the only two things that appear to be consistently present in all OO languages are: 1) some notion of object identity as distinct from object state, and 2) runtime polymorphic dispatch.

3. epcoa ◴[15 Oct 24 18:37 UTC] No.41851677[source]▶
> 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.