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

Principles for C programming

drewdevault.com

Post reply on HN
Print view View original

141–149 of 149 posts

Re: Principles for C programming

#141

Post by Aldo_MX »

huhtenberg wrote: post #133
torrent-of-ions wrote: post #82

Earlier quoted context omitted.

Surely a simple naming convention such as a capital letter for compound types is sufficient?

Or something as basic as foo_s bar_u baz_e for structs, unions and enums respectively. Perhaps even splurge on xyz_f for function pointers... though that's getting recklessly close to the Hungarian notation :)

I love Hungarian Notation, I mean, it's pretty intuitive that LPCTSTR is a long pointer to a (zero-terminated) constant TCHAR string.

I definitely never panicked as a kid when I saw WINAPI-related code.

Re: Principles for C programming

#142

Post by hackits »

wruza wrote: post #131
hackits wrote: post #116

Earlier quoted context omitted.

Worked on a number of different projects clearly from a maintence perspective. From C,C++ mostly around VBS2/VBS3 (Operation Flashpoint) and VSS Simulation systems. Moved on from C/C++ simulation market when the money wasn't really in it unless you're the sales people or upper management. Kind of drives it home when you bike into work and all management are driving BMW ect.. This was a startup that I took a major pay…

One of the main reasons why I visit HN is real life experience & philosophy stories like that. Thanks!

One of the video that can articulate the whole thing better than me is (https://www.youtube.com/watch?v=QM1iUe6IofM)

It was a long winded written rant. I still use OOP but its more or less glorified name spaces with functions. Today I rather work on procedural code than OOP code. It may have bugs, it may have their own little quirks but its like a old rusted vehicle that still keeps going.

Re: Principles for C programming

#143

Post by nonsince »

zild3d wrote: post #126
keithnz wrote: post #76

1) Learn Compiler Design 2) Write a Compiler for a better language 3) In new language, write a compiler for your new language 4) Retire from C programming, occasionally come to Hacker News to reminisce about C programming and ways to avoid shooting yourself in the foot

or 1) Learn Embedded Design 2) Stay in C for another few decades

I'm in embedded, but I have a fair measure of autonomy so I've got some Rust code on our device. If nothing else, the cross-compilation story for Rust is absolutely _beautiful_. Just stick the toolchain path in a config file somewhere.

Re: Principles for C programming

#144

Post by torrent-of-ions »

jabot wrote: post #61

> GNU is a blight on this Earth, do not let it infect your code. Can someone explain this sentiment to me? I know about licensing and philosophical criticisms, but are there any _technical_ faults?

Is there anything popular which does not have a large amount of criticism directed towards it? Anything at all?

Re: Principles for C programming

#145

Post by irundebian »

arkj wrote: post #79

>>Avoid magic. Do not use macros What a put off!!! If you are programming in C in the 21st century then you better know what you are doing. And this whole advice is for dilettantes (no offense). C is no longer a choice language to demonstrate high level programming principles (not that you can't do it but it's not for the lazy), there's a host of other languages that do that better. But if you are interested to reach…

Could you give me a reason why to use macros instead of typed static inline functions?

If it's performance, where can I find something like a rationale documentation or empirical measurements of this list implementation?

Re: Principles for C programming

#146

Post by irundebian »

cperciva wrote: post #69
Sir_Cmpwn wrote: post #58

Earlier quoted context omitted.

>I don't think you understand. At a minimum, you would need parsenumi, parsenuml, parsenumll, parsenumimax, parsenumu, parsenumul, parsenumull, parsenumumax, parsenumi8, parsenumi16, parsenumi32, parsenumi64, parsenumu8, parsenumu16, parsenumu32, parsenumu64, parsenumf, and parsenumd. Fair. I still don't really see the value in this, though. The only real gain is from doing the range check, and that's niche enough th…

that's niche enough Not niche at all. You should have a range check on pretty much every value you accept from a command-line option.

cperciva, sorry, but you're these type of people who should be kept away from security critical code.

It's not that I would doubt in any way your deep knowledge of the C language, quite the opposite, it's just your arrogance, your mentality of elitism and your belief, that you don't belong to the people, who are making mistakes (like "because of XYZ years of experience" bullshit).

IMHO if you want to write good code (especially safety-critical code) it is a FUCKING MUST to believe that you or others who are working on your code will make mistakes, caused by badly readable code. The mental model caused by reading your code have to be minimized as heavy as possible.

But I guess the problem of people like you with writing clean and readable code is, that you can't show your knowledge and experience built over several years. This behavior reminds be of philosophers (also social scientists) criticized by Karl Popper as "obscurantists", which are preferring to describe simple issues in a complex language to show how intellectual they are, although they could be well described in a clean and a simple way, so that everybody understands them.

I'm highly surprised that your still behaving arrogant, advocating complex macros and act as you have never made a mistake when dealing with code. Open your eyes and deal with the fact that YOU are one of the people who devaluated the whole security promise of a security critical software [0]. YOU are one of the people as we all are, that are making mistakes. Be it by deliberately removing increment operators of an IV or by a fault caused by a misunderstand of unnecessary complex code.

[0] http://www.daemonology.net/blog/2011-01-18-tarsnap-critical-...

Re: Principles for C programming

#147

Post by dTal »

falcolas wrote: post #111
eps wrote: post #97

Earlier quoted context omitted.

Typedefs are useful for creating short-hand names for otherwise long or complicated type definitions. Saving 7 (6 for 'struct' + space) characters is as good use for typedef as any other.

You only have to write each set of seven characters once; yes, typing will require a bit more effort. However, we shouldn't optimize code for the ease of writing, we should be optimizing for the ease of reading. Write once, read many. `struct foo` is a bit more instructive when understanding code than `foo`; at worst, they read the same to someone familiar to the codebase, at best they prevent the need to flip back a…

>Typedefs are useful for abstracting the underlying storage mechanism for a scalar (so you can i.e. change it on different archictures or in a future release without breakage), not for saving yourself 6 characters of typing.

Re: Principles for C programming

#148

Post by renox »

userbinator wrote: post #93
MaulingMonkey wrote: post #54

Earlier quoted context omitted.

> For example, "Do not use fixed size buffers". It's all very fine, but 1) it can be exploited as well if someone managed to fudge the size you are going to allocate Fuzzing really underscored just how terrible "dynamically sized buffers" are to me as well. Even if your logic is perfectly correct (e.g. no possibility of buffer overflows), something as simple as deserializing a length-prefixed array needs a quota or c…

I prefer attempting to find an O(1)-space algorithm over dynamic allocation, which I suppose means using fixed-size buffers anyway. In my experience it is surprising how many programmers will --- regardless of language --- tend to settle for O(n)-space or higher algorithms when just a little more thought would produce a simpler O(1). Line numbering is a common example of this.

Could you explain your point about line numbering?

Re: Principles for C programming

#149

Post by MaulingMonkey »

renox wrote: post #148
userbinator wrote: post #93

Earlier quoted context omitted.

I prefer attempting to find an O(1)-space algorithm over dynamic allocation, which I suppose means using fixed-size buffers anyway. In my experience it is surprising how many programmers will --- regardless of language --- tend to settle for O(n)-space or higher algorithms when just a little more thought would produce a simpler O(1). Line numbering is a common example of this.

Could you explain your point about line numbering?

Take, for example, displaying the context source code for an error when you know the file and lineNo of the error.

A naive approach would be to read the entire file into an array and then to output the lines [lineNo-context..lineNo+context], possibly with line numbers prefixed. This is O(N) memory with regards to the size of the file being processed. A 8GB source file will crash your program when built for 32-bit.

Another approach is to read and discard until you've discarded lineNo-context '\n' characters, then copy chunks from your source directly to the output until you've read another 2*context+1 characters. This is O(1) memory (strictly speaking, you could do it byte-by-byte with an integer counter or two - practically you might have a fixed size buffer to read/write faster) and would allow you to handle even 1TB files sanely.

To be fair, I'm often guilty of the naive approach myself :)

Post reply on HN