101–110 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.
Deep C Secrets.
One caveat, though, this book is from the mid-nineties, so some parts are a little dated. Still, very much worth reading.
Avoid magic. Do not use macros. Disagree. Use magic, especially macros, in ways such that your code becomes easier, not harder, to understand . A few examples from my own code: 1. My "elastic arrays" ( https://github.com/Tarsnap/libcperciva/blob/master/datastruc... and .c) allow me to write ELASTICARRAY_DECL(STRLIST, strlist, const char *); and get a data structure STRLIST which contains an arbitrary number of string…
>1 I'm conflicted about this one. I choose not to try and emulate generics with macros because adding language features with macros is a terrible idea. On the other hand, I recognize the problem with void*. It's a matter for debate but I definitely fall on the "don't use macros for this" side. >2 This is a case where I would rather write more code than rely on magic. You have to have this awful hacky opaque implement…
For me clearly named macro beats the need to parse few lines of code even if they are very clear and readable.
>Do not use macros. Do not use a typedef to hide a pointer or avoid writing “struct”. Avoid writing complex abstractions. Keep your build system simple and transparent. Don’t use stupid hacky crap just because it’s a cool way of solving the problem. Heh, good luck avoiding the use of macros in sufficiently complex projects - sometimes C just can't use some control structures in an elegant manner without using macros…
>Do not use macros. Do not use a typedef to hide a pointer or avoid writing “struct”. Avoid writing complex abstractions. Keep your build system simple and transparent. Don’t use stupid hacky crap just because it’s a cool way of solving the problem. Heh, good luck avoiding the use of macros in sufficiently complex projects - sometimes C just can't use some control structures in an elegant manner without using macros…
Can you provide an example of control structures that cannot be used in elegant manner without macros? I honestly fail to think of any example. However I generally agree, that macros are pretty much unavoidable. Include guards are implemented using macro constants. It is pretty much the only portable way to force inlining (in some cases this might be necessary). Variadic macros are a easier to create that variadic fu…
As for include guards one has to look really hard [1] to get a compiler that does not support #pragma once.
I would suggest increasing the font-weight of your bolded text. I could not differentiate the two when skimming over the article; only when I read very carefully did I notice that you had somethings bolded.
Earlier quoted context omitted.
To be honest I would just have your library offer a function that does it your fancy way. I agree that there could be better integer parsing functions, I disagree that they should be macros. >Not at all. The point is to have self-contained routines which Just Work in order to ensure that the rest of the code is easier to read and maintain. Self-contained routines that are completely unmaintainable and unintelligible…
To be honest I would just have your library offer a function that does it your fancy way. It's not possible to have a single function do this. Not possible to have any finite number of functions do this if, like me, you want to support all floating-point and integer types. Self-contained routines that are completely unmaintainable and unintelligible to anyone but you, though. All of my macros are intelligible to anyo…
Earlier quoted context omitted.
> They are "protected", yes, but their mere presence encourages people to use them. There's no reason to use asprintf, but glibc makes it available so some software uses it. That software is now non-portable. I think asprintf is useful - it replaces an ugly "malloc-realloc-snprintf-loop"... On exposing non-portable functions/features: - OpenBSD does it (pledge) - Freebsd/NetBSD do it (kqueue) - ... I'm certain other…
>I think asprintf is useful - it replaces an ugly "malloc-realloc-snprintf-loop"... Well, implement it yourself then. It's really not hard to live without, though. I don't know about this loop you're talking about but I just do this: int len = snprintf(NULL, 0, "fmt", ...); char *foo = malloc(len + 1); snprintf(foo, len, "fmt", ...); Easy to wrap that up in your own asprintf function if you would find that useful. An…
Yeah, let's reinvent the wheel anytime something is not available on all platforms in the world, wether or not you intent to target them...
If I target GNU systems, why can't I use GNU features ? If people really want to port my code, let them do so.
> 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?
For example, Linux still does not have a sane DNS resolver interface that is useful without GNU-C library. With move to containers that lead to many issues like inability to resolve link-local names etc.
Earlier quoted context omitted.
Targeting expresses expectations about an environment. "Do not assume" would be contradictory to those explicit expectations.
And since we can follow that thought process, we are smart enough to infer the meaning of the advice given ("do not assume") in the proper context, can we not? It's obvious to me we both can, so why the hell are you wasting our time with useless pedantry?
The article is clearly heavy on the absolutes (eg: "Under no circumstances should you ever use"), and the grandparent comment critized this, and provided a good counterexample.
But you, ironically, chose to assume what the author meant by "do not assume".
Earlier quoted context omitted.
So in your opinion the problem is "only" one of portability to non-gnu systems? I thought the author also implied that GNU was technologically inferior and/or problematic. That would interest me...
Probably the ubiquitous "bloat" issue some die-hard C-heads have. But that's his prerogative, I was just pointing out that the specific context points towards portability issues.
However, since gnu is a political umbrella project which does not necessarily value code quality, we see a lot of unnecessary complexity arising from the focus on creating working "free" software and not minding the quality much.
Anyone who ever touched GNU autotools will confirm that the bloat issue is real. No need to be a diehard C head.