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

My personal C coding style as of late 2023

nullprogram.com

Post reply on HN
Print view View original

411–420 of 466 posts

Re: My personal C coding style as of late 2023

#411

Post by paulddraper »

layer8 wrote: post #204
_old_dude_ wrote: post #180

Earlier quoted context omitted.

I remember James Gosling saying, a long time ago, that the whole class should be either mutable or not so you do not need to tag some methods with const. The consequence is that you may define two classes, one non-mutable and one mutable like String/StringBuilder.

It means you have to triplicate each mutable class, because besides the immutable variant you also need the common interface (e.g. CharSequence), in order to pass mutable instances to read-only functions.

No, there are two classes -- mutable and immutable -- that both implement the immutable interface.

Re: My personal C coding style as of late 2023

#412

Post by circuit10 »

billfruit wrote: post #382
circuit10 wrote: post #303

Earlier quoted context omitted.

It’s longer than it needs to be when you’re typing it out so many times

What are we trying to optimize, the number of characters to type or clarity/readbility?

Both I guess? I don’t think the extra length helps with readability at all

Re: My personal C coding style as of late 2023

#413

Post by epcoa »

kazinator wrote: post #408
epcoa wrote: post #407

Earlier quoted context omitted.

> What I mean by "bend the rules of arithmetic" is that if we decrement from zero, we suddenly get a large value. Yes completely consistent with rules of modular arithmetic. A programmer ought to be able to extend math horizons beyond preschool. Which is ironic because I can explain this concept to my 6 year old on a clock face and it’s easy for them to grasp. > Unsigned tricks with circular buffer indices will not d…

In the N3096 working draft it is written: "The sign representation defined in this document is called two’s complement. Previous revisions of this document additionally allowed other sign representations." Non-two's complement machines are museum relics, and are no longer going to be supported by ISO C. > why clutter things with extra masking. Because even if the circular buffer is a power of two, its size doesn't ne…

> If the buffer doesn't have a width of 256, 65536, or 4294967296, then you're out of luck

Why so much hyperbole? You’re not out of luck. You can atomic increment/add the unsigned no matter the buffer size. You don’t worry about overflow like you would with a signed type. You can mask after.

And you continue to avoid answering the simple question: what is the advantage of the signed type. I’ve already outlined the one with unsigned, especially with atomics.

Re: My personal C coding style as of late 2023

#415

Post by kazinator »

epcoa wrote: post #409
kazinator wrote: post #408

Earlier quoted context omitted.

In the N3096 working draft it is written: "The sign representation defined in this document is called two’s complement. Previous revisions of this document additionally allowed other sign representations." Non-two's complement machines are museum relics, and are no longer going to be supported by ISO C. > why clutter things with extra masking. Because even if the circular buffer is a power of two, its size doesn't ne…

So then what is the advantage of using a signed type in this case? And C++20 already standardized it I know that I already acknowledged this. Should I go back and rewrite all the old correct code so you feel better?

The main advantage is not foisting unsigned on the user of the API.

(You can do that while using unsigned internally, but then you have to convert back and forth.)

The most important decision is what is the index type at the API level of the circular buffer, not what is inside it. But it's nicer if you can just use the API one inside.

The sizeof operator yielding the type size_t which is unsigned has done a lot of harm. Particularly the way it spread throughout the C library. Why do we have size_t being unsigned? Because on small systems, where we have 16 bit sizes, signed means limiting to 32767 bytes, which is a problem. In all other ways, it's a downer. Whenever you mention sizeof, you have unsigned arithmetic creeping into the calculation.

The author of the above blog article has the right idea to want a sizeof operator that yields ptrdiff_t instead of size_t. (Unfortunately, the execution is bungled; he redefined a language keyword as a macro, and on top of that didn't wrap the macro expansion in parentheses, even.)

Re: My personal C coding style as of late 2023

#416

Post by kazinator »

epcoa wrote: post #413
kazinator wrote: post #408

Earlier quoted context omitted.

In the N3096 working draft it is written: "The sign representation defined in this document is called two’s complement. Previous revisions of this document additionally allowed other sign representations." Non-two's complement machines are museum relics, and are no longer going to be supported by ISO C. > why clutter things with extra masking. Because even if the circular buffer is a power of two, its size doesn't ne…

> If the buffer doesn't have a width of 256, 65536, or 4294967296, then you're out of luck Why so much hyperbole? You’re not out of luck. You can atomic increment/add the unsigned no matter the buffer size. You don’t worry about overflow like you would with a signed type. You can mask after. And you continue to avoid answering the simple question: what is the advantage of the signed type. I’ve already outlined the on…

Comment said "why clutter with extra masking" (just use the unsigned types).

Although unsigned types have no overflow, running to them as some sort of safe refuge is a mistaken knee-jerk reaction.

Re: My personal C coding style as of late 2023

#419

Post by layer8 »

paulddraper wrote: post #411
layer8 wrote: post #204

Earlier quoted context omitted.

It means you have to triplicate each mutable class, because besides the immutable variant you also need the common interface (e.g. CharSequence), in order to pass mutable instances to read-only functions.

No, there are two classes -- mutable and immutable -- that both implement the immutable interface.

Yes, so three classes. I’m counting a Java interface as a class, because it is the same as a purely abstract class. In any case, three different named types.

As a side note, I would say the interface is unmodifiable, not immutable, because references of the interface type may refer to mutable instances that can mutate while you use it through the interface. Immutable = doesn’t change state, unmodifiable = you can’t change it’s state via that reference (but it might change it’s state due to other concurrent code holding a mutable reference). This nomenclature comes from the “unmodifiable” collection wrappers in Java, which don’t make the underlying object immutable.

Re: My personal C coding style as of late 2023

#420

Post by mattpallissard »

Uptrenda wrote: post #84

IMO, defining your own types is one step too far. Now everyone who is already familiar with C types has to learn your own quirky system to understand one program. I think it does probably make sense to be specific about the sizes though e.g. using uint32_t over just uint (and expecting to receive some architecture-dependent size you might not get with uint.) These types should be defined in the right header (I think…

> Now everyone who is already familiar with C types has to learn your own quirky system

Oh I dunno. On one hand yeah learning a quirky system is an annoyance at times. On the other hand when you're coming from a language with a real type system dealing with custom types is standard operating procedure.

I've had to patch a lot of C over the years. I can't say I've ever been bothered by types. It's always the usual suspects; hard coded offsets peppered throughout the codebase, stack smashing, baby's first callback implementation, "parsing" that omits lexing/tokenizing, archaic business logic that may-or-may not have ever been correct.

Post reply on HN