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

C Style: My favorite C programming practices (2014)

github.com

Post reply on HN
Print view View original

61–70 of 139 posts

Re: C Style: My favorite C programming practices (2014)

#61

Post by nine_k »

teddyh wrote: post #54
ack_complete wrote: post #19

Earlier quoted context omitted.

I'm torn both ways on the double issue. On the one hand, doubles are much more widely supported these days, and will save you from some common scenarios. Timestamps are a particular one, where a float will often degrade on a time scale that you care about, and doubles not. A double will also hold any int value without loss (on mainstream platforms), and has enough precision to allow staying in world coordinates for 3…

I think you used the word “panacea” incorrectly. Judging by context, I would guess that the word “band-aid” would better convey your intended meaning.

A "panacea" is something that cures.every illness. 64-bit floats could do just that, in the cases listed. The cost of it may be higher than one cares to pay though.

And when the cure fails to be adequate, well, it becomes a band-aid, a temporary measure in search of a real solution.

Re: C Style: My favorite C programming practices (2014)

#62

Post by 0xTJ »

sph wrote: post #58

> Always write to a standard, as in -std=c11. Don't write to a dialect, like gnu11. Try to make do without non-standard language extensions: you'll thank yourself later. Why not? Do people really care about porting their toy project to another compiler? If portability is a goal, avoid extensions, but not all projects need to be portable. I'm writing an Operating System, and I do not care it if compiles on Clang or MS…

Even when I'm writing a toy operating system, or other toy projects, I personally always try to use the standard options like -std=c11 (though don't have anything against people who use the dialect option).

I'm happy to use compiler extensions, but I'll use __asm__ instead of asm, and use __extension__ as needed. I've done some neat but truly upsetting things with compiler extensions in my hobby code, especially once I combine them with macros. I'm particularly "proud" of the mutex macros in a toy OS of mine, which wrap a statement inside for loops and switch statements for automatic release of the mutex, unless it's requested that it stay locked. There, I originally used compiler extensions to release the mutex on scope exit, but switched to non-compiler-extension code for the actual functions, and just using the extensions for checking that the code using the macros didn't break the "contracts" on what is allowed in those statements, and how they can be exited.

It's the same reason that I'm always explicit about the size of integers, using stdint, even if I know that an int is 32-bit on a particular platform.

Re: C Style: My favorite C programming practices (2014)

#63

Post by nine_k »

f1shy wrote: post #22
kleiba wrote: post #12

Earlier quoted context omitted.

Agree. This 80 character limit stems from a time where terminals could only display comparatively few characters in a line, a limit we haven't had in decades as screen resolutions grew. Another argument for shorters lines is that it is much harder for us to read any text when lines get too long. There's a reason why we read and write documents in portrait mode, not landscape. But in sum, I don't think there's a need…

> This 80 character limit stems from a time where terminals could only display comparatively few characters in a line, a limit we haven't had in decades as screen resolutions grew. The 80 char rule has little to do with old monitors. Has to do with ergonomics, and is why any good edited and typeset book will have between 60 and 80 characters per line.

Monitors are too new. Punch cards have 80 columns. I think this even pre-dates the use of teletypes with electronic computers.

Re: C Style: My favorite C programming practices (2014)

#64

Post by orthoxerox »

ack_complete wrote: post #19
a_e_k wrote: post #2

I feel like I probably agree with about 80% of this. It also seems like this would apply fairly well to C++ as well. One thing that I'll strongly quibble with: "Use double rather than float, unless you have a specific reason otherwise". As a graphics programmer, I've found that single precision will do just fine in the vast majority of cases. I've also found that it's often better to try to make my code work well in…

I'm torn both ways on the double issue. On the one hand, doubles are much more widely supported these days, and will save you from some common scenarios. Timestamps are a particular one, where a float will often degrade on a time scale that you care about, and doubles not. A double will also hold any int value without loss (on mainstream platforms), and has enough precision to allow staying in world coordinates for 3…

Are there C++ libs that use floating points for timestamps? I was under the impression that most stacks have accepted int64 epoch microseconds as the most reasonable format.

Re: C Style: My favorite C programming practices (2014)

#65

Post by JKCalhoun »

a_e_k wrote: post #2

I feel like I probably agree with about 80% of this. It also seems like this would apply fairly well to C++ as well. One thing that I'll strongly quibble with: "Use double rather than float, unless you have a specific reason otherwise". As a graphics programmer, I've found that single precision will do just fine in the vast majority of cases. I've also found that it's often better to try to make my code work well in…

> I feel like I probably agree with about 80% of this.

What I was thinking too. There's something in here to offend everyone, and that's probably a good thing.

Re: C Style: My favorite C programming practices (2014)

#66

Post by LeoNatan25 »

xipix wrote: post #42
LeoNatan25 wrote: post #24

> 80-characters-per-line is a de-facto standard for viewing code. Readers of your code who rely on that standard, and have their terminal or editor sized to 80 characters wide, can fit more on the screen by placing windows side-by-side. This is one of the silliest practices to still be enforced or even considered in 2024. “Readers” should get a modern IDE/text editor and/or modern hardware.

A proportional font really helps ergonomics too.

This is probably a snarky reply, but here is the serious answer: proportional fonts, with appropriate kerning, is a lot more legible than monospaced font. There is a reason why the press moved into that direction once it was technically feasible. But the same people that bring books as an example why 80 character line length should be enforced would gag at the notion of using proportional fonts for development. It just goes to show that none of these things actually matter, it’s just legacy patterns that remain in-place from sheer inertia, with really very little relevancy today other than the inertia of the past.

Re: C Style: My favorite C programming practices (2014)

#67

Post by gpderetta »

orthoxerox wrote: post #64
ack_complete wrote: post #19

Earlier quoted context omitted.

I'm torn both ways on the double issue. On the one hand, doubles are much more widely supported these days, and will save you from some common scenarios. Timestamps are a particular one, where a float will often degrade on a time scale that you care about, and doubles not. A double will also hold any int value without loss (on mainstream platforms), and has enough precision to allow staying in world coordinates for 3…

Are there C++ libs that use floating points for timestamps? I was under the impression that most stacks have accepted int64 epoch microseconds as the most reasonable format.

> int64 epoch microseconds

surely nanoseconds is the truth.

Re: C Style: My favorite C programming practices (2014)

#68

Post by zbentley »

teddyh wrote: post #54
ack_complete wrote: post #19

Earlier quoted context omitted.

I'm torn both ways on the double issue. On the one hand, doubles are much more widely supported these days, and will save you from some common scenarios. Timestamps are a particular one, where a float will often degrade on a time scale that you care about, and doubles not. A double will also hold any int value without loss (on mainstream platforms), and has enough precision to allow staying in world coordinates for 3…

I think you used the word “panacea” incorrectly. Judging by context, I would guess that the word “band-aid” would better convey your intended meaning.

Perhaps "placebo" was intended?

Re: C Style: My favorite C programming practices (2014)

#69

Post by AnimalMuppet »

sdk77 wrote: post #52
a_e_k wrote: post #2

I feel like I probably agree with about 80% of this. It also seems like this would apply fairly well to C++ as well. One thing that I'll strongly quibble with: "Use double rather than float, unless you have a specific reason otherwise". As a graphics programmer, I've found that single precision will do just fine in the vast majority of cases. I've also found that it's often better to try to make my code work well in…

There are popular embedded platforms like STM32 that don't have hardware double support, but do have hardware float support. Using double will cause software double support to be linked and slow down your firmware significantly.

OK, but if you're writing for that kind of platform, you know it. Don't use double there? Sure. "Don't use double on non-embedded code just because such platforms exist" doesn't make sense to me.

Sure, my code could maybe run on an embedded platform someday. But the person importing it probably has an editor that can do a search and replace...

Re: C Style: My favorite C programming practices (2014)

#70

Post by astrobe_ »

sph wrote: post #58

> Always write to a standard, as in -std=c11. Don't write to a dialect, like gnu11. Try to make do without non-standard language extensions: you'll thank yourself later. Why not? Do people really care about porting their toy project to another compiler? If portability is a goal, avoid extensions, but not all projects need to be portable. I'm writing an Operating System, and I do not care it if compiles on Clang or MS…

The recommendation of using the most recent standard is very slightly inconsistent with this, because in rare cases your code could be reused in weird embedded targets that only have an unmaintained proprietary C compiler. That was already rare in 2014 I think. Still, the situation might arise, just like you can still can find AS/400 machines or Cobol in production.
Post reply on HN