91–100 of 149 posts
I've recently been reading Scott Meyers' Effective (Modern) C++ books. They are fantastic - can anyone recommend something similar for C? I.e. books that assume you're familiar with the language, but explains pitfalls and best practices in a practical way.
>>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…
Magic stuff are for wizards, and most of us are not.
I disagree with quite a few of them. The title should be "Principle for C programming ON UNUX BASED SYSTEMS". C programming is quite a bit wider that this, and some of the typical points here are no-no if you want to write /portable/ C. 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, and 2) on some pla…
> 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…
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.
Earlier quoted context omitted.
"Do not assume" doesn't really mean or imply "do not target", so stop being defensive. It's good advice.
Targeting expresses expectations about an environment. "Do not assume" would be contradictory to those explicit expectations.
It's obvious to me we both can, so why the hell are you wasting our time with useless pedantry?
>>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…
This should have been shorten to "Avoid magic". This is applicable to any language, not just to C. Magic stuff are for wizards, and most of us are not.
IMHO if you want to become an expert in C and C++, you must be able to read Asm and understand what the machine is actually doing.
A very relevant article on this same idea: http://www.linusakesson.net/programming/kernighans-lever/
https://sircmpwn.github.io/2017/03/15/How-I-learned-to-stop-...
Earlier quoted context omitted.
Not sure I follow. > scalars So you would typedef the scalars then? If you don't, then scalars will be the built-in types (which you'd presumably know well) and then all other type names will be typedef'ed structs/unions, still making it trivial to recognize them as such.
Yes, I think typedefing scalars is fine. 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.
>>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…
[1] https://github.com/freebsd/freebsd/blob/master/sys/sys/tree....
Earlier quoted context omitted.
This should have been shorten to "Avoid magic". This is applicable to any language, not just to C. Magic stuff are for wizards, and most of us are not.
"Magic" becomes obvious common-sense once you understand. The overall theme of the parent comment is that we should try to understand instead of giving up, because that's what makes us learn and become better at the language. IMHO if you want to become an expert in C and C++, you must be able to read Asm and understand what the machine is actually doing. A very relevant article on this same idea: http://www.linusakes…
Earlier quoted context omitted.
That said, people sometimes ate grading your code based on performance. Good algorithms often win over simplistic ones.
I'd say when you have big n, smart algorithms O(n) are better. But most of the time you have small n. better to optimize just the real big N in your program, for what you profiled, than using complex and "optimized" algos when N (I cannot retrieve the article this was taken from)