5 ms·

>>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 adv

by arkj 10y ago

>>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 close to the machine (eg: you program needs a direct view of memory) then C is 'the' choice even today. Look at the kernel list.h [0], it's a beautiful piece of code, and how concisely it uses macros. So the real advice to those starting out in C is to be bold and get immersed in all the things that people say you should not do and then let simplicity emerge. In other words, 'simplicity' of the novice and of the experienced share the same word but are two different concepts from two different points of view. [0]https://github.com/torvalds/linux/blob/master/include/linux/list.h https://github.com/torvalds/linux/blob/master/include/linux/...

mfukar 10y ago
That is both good and bad advice. Good because yes, programmers must quickly look at others' code and be exposed to the idioms and the anti-patterns. Bad because just by looking at something the newbies don't immediately connect it with one category or another, instruction is necessary to avoid them resorting to anti-patterns (as it is ironically the case with many things Linux).
jackmott 10y ago
I touch C only occasionally, so I'm not a guru. But I love macros. I want all languages to have macros.
yitchelle 10y ago
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.
- userbinator 10y ago
  "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.linusakesson.net/programming/kernighans-lever/ http://www.linusakesson.net/programming/kernighans-lever/
  - thlst 10y ago
    Magic has nothing to do with understanding assembly. Magic simply is probably undocumented piece of code (they aren't even self-documenting), that in order to understand you have to ask the author about it. There's no magic if you understand the code right away, or by looking up some reference.
  - attractivechaos 10y ago
    > "Magic" becomes obvious common-sense once you understand. I fully agree. Packing data into a binary array, popcount with bit fiddling, macros for generics, etc may seem "magic" to some, but they can be useful especially in performance-critical code. Once you understand these "magic", they are just some common pieces in your toolbox. C is a simple language. Learning C plus such "magic" still takes much less time than grasping the entire C++.
attractivechaos 10y ago
See also tree.h from freebsd [1]. If you need a generic red-black tree, this is probably your best choice in C. [1] https://github.com/freebsd/freebsd/blob/master/sys/sys/tree.h https://github.com/freebsd/freebsd/blob/master/sys/sys/tree....
camtarn 10y ago
I'm coding in C89 because I'm writing software for industrial embedded controllers. Future maintainers of this software are more likely to be electronic engineers than programmers, so "keep it simple and don't use magic" is actually extremely good advice. That said, my code does use a couple of macros, but only to do stuff that would be very long-winded and/or impossible without, and using malloc at all is very much frowned upon: storage should either be declared ahead of time in special .var files, or on the stack.
- axoltl 10y ago
  Yeah, in general I agree with the article, the 'malloc all your memory' part is something I disagree with heavily. Outside of the fact that many malloc and calloc implementations don't particularly deal well with integer overflow[0], it introduces non-determinism into your code. MISRA C even forbids the use of dynamic memory allocation. In fact, the environments where C shines oftentimes won't even have a dynamic allocator... [0] Try allocating ((size_t)-1) bytes. Quite a few implementations will give you a pointer back! They'll add some space for a header, or round up the size to the nearest n-byte boundary. This problem's compounded by the fact people assume passing unsanitized input to malloc effectively sanitizes it.
irundebian 10y ago
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?

by arkj 10y ago

mfukar 10y ago

That is both good and bad advice. Good because yes, programmers must quickly look at others' code and be exposed to the idioms and the anti-patterns. Bad because just by looking at something the newbies don't immediately connect it with one category or another, instruction is necessary to avoid them resorting to anti-patterns (as it is ironically the case with many things Linux).

jackmott 10y ago

I touch C only occasionally, so I'm not a guru. But I love macros. I want all languages to have macros.

yitchelle 10y ago

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.

userbinator 10y ago
"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.linusakesson.net/programming/kernighans-lever/ http://www.linusakesson.net/programming/kernighans-lever/
- thlst 10y ago
  Magic has nothing to do with understanding assembly. Magic simply is probably undocumented piece of code (they aren't even self-documenting), that in order to understand you have to ask the author about it. There's no magic if you understand the code right away, or by looking up some reference.
- attractivechaos 10y ago
  > "Magic" becomes obvious common-sense once you understand. I fully agree. Packing data into a binary array, popcount with bit fiddling, macros for generics, etc may seem "magic" to some, but they can be useful especially in performance-critical code. Once you understand these "magic", they are just some common pieces in your toolbox. C is a simple language. Learning C plus such "magic" still takes much less time than grasping the entire C++.

attractivechaos 10y ago

See also tree.h from freebsd [1]. If you need a generic red-black tree, this is probably your best choice in C. [1] https://github.com/freebsd/freebsd/blob/master/sys/sys/tree.h https://github.com/freebsd/freebsd/blob/master/sys/sys/tree....

camtarn 10y ago

I'm coding in C89 because I'm writing software for industrial embedded controllers. Future maintainers of this software are more likely to be electronic engineers than programmers, so "keep it simple and don't use magic" is actually extremely good advice. That said, my code does use a couple of macros, but only to do stuff that would be very long-winded and/or impossible without, and using malloc at all is very much frowned upon: storage should either be declared ahead of time in special .var files, or on the stack.

axoltl 10y ago
Yeah, in general I agree with the article, the 'malloc all your memory' part is something I disagree with heavily. Outside of the fact that many malloc and calloc implementations don't particularly deal well with integer overflow[0], it introduces non-determinism into your code. MISRA C even forbids the use of dynamic memory allocation. In fact, the environments where C shines oftentimes won't even have a dynamic allocator... [0] Try allocating ((size_t)-1) bytes. Quite a few implementations will give you a pointer back! They'll add some space for a header, or round up the size to the nearest n-byte boundary. This problem's compounded by the fact people assume passing unsanitized input to malloc effectively sanitizes it.

irundebian 10y ago

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?