Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The C23 edition of Modern C

gustedt.wordpress.com

Post reply on HN
Print view View original

31–40 of 360 posts

Re: The C23 edition of Modern C

#31

Post by bobmcnamara »

f1shy wrote: post #14
com2kid wrote: post #11

Earlier 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?

Templating on pixel classes so that a blitter builds all supported pixel paths separately and inlines them.

Yes you can do it less cleanly with macros or inline functions. But you can't do it performantly with struct and function pointers.

Re: The C23 edition of Modern C

#32

Post by jejdjdbd »

card_zero wrote: post #27
jpcfl wrote: post #8

Earlier 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?

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

Re: The C23 edition of Modern C

#35

Post by tjoff »

raluk wrote: post #19
f1shy wrote: post #14

Earlier quoted context omitted.

What would be an example of "simple OO here and there" that cannot be done cleanly in plain C?

RAII

The killer feature of RAII is when combined with exceptions. But sneaking in exceptions in an embedded C project isn't something I'd encourage or recommend.

C++ imo doesn't offer anything compelling for the embedded usecase. Especially not considering all the footguns and politics it brings.

You can of course be strict and diligent about it but if you are you are pretty much just writing C anyway. Better to do it explicitly.

Allowing the use of the C++ standard library has been one of my biggest regrets (not that it was my decision to make, I fought it).

Re: The C23 edition of Modern C

#36

Post by int_19h »

f1shy wrote: post #22
adamrezich wrote: post #21

Earlier quoted context omitted.

Namespaces, methods.

Namespaces is not object orientation, is it? Am I missing something? You can place functions (methods) inside of structs in C23, can't you?

You can handcode vtables in C, just as you can handcode loops in assembly (i.e. it works but it's verbose, not particularly readable, and brings more footguns).

But why would you do that if you have an instrument that lets you work at the same level as C, but with methods provided as a proper abstraction that maps exactly to what you'd have written yourself anyway?

Re: The C23 edition of Modern C

#37

Post by Jtsummers »

bwidlar wrote: post #12
auggierose wrote: post #7

Table of contents in the sidebar doesn't work properly for me when I click on an entry (in macOS Preview).

I just test some links in the table of content, works fine for me. Using zathura pdf reader.

Also works in Adobe and Firefox, but doesn't work in Chrome and Edge.

Re: The C23 edition of Modern C

#38

Post by int_19h »

f1shy wrote: post #30
staunton wrote: post #25

Earlier 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…

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.

Re: The C23 edition of Modern C

#39

Post by card_zero »

jejdjdbd wrote: post #32
card_zero wrote: post #27

Earlier quoted context omitted.

Because people choose to use pre-increment by default instead of post-increment? Why is that?

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.

Re: The C23 edition of Modern C

#40

Post by tialaramex »

card_zero wrote: post #27
jpcfl wrote: post #8

Earlier 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?

Why use this operator? Like most C and C++ features the main reason tends to be showing off, you learned a thing (in this case that there are four extra operators here) and so you show off by using it even if it doesn't make the software easier to understand.

This is not one of those beginner -> journeyman -> expert cycles where coincidentally the way you wrote it as a beginner is identical to how an expert writes it but for a very different reason. I'd expect experts are very comfortable writing either { x = k; k += 1; } or { k += 1; x = k; } depending on which they meant and don't feel an itch to re-write these as { x = k++; } and { x = ++k; } respectively.

I'm slightly surprised none of the joke languages add equally frivolous operators. a%% to set a to the remainder after dividing a by 10, or b** to set b as two to the power b or some other silliness.

Post reply on HN