Hacker News Reader

Comment by CapacitorSet | Hacker News Reader

>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 or custom abstractions.

View on HN

> Do not use macros.

Sir, yes, sir. I will throw away "offsetof" and "container_of" right now, just give me a moment.

> Do not use a typedef to hide a pointer or avoid writing “struct”

Somewhat agree with the former, but completely disagree with the latter. If there's a single thing that is not right with C is its excessive verbosity in places where none is needed.

Not typedef'ing your structs forces you to use extra 7 characters per type mention for no clear benefit. To put it differently - if NOT having "struct" in front of a type name has any effect on readability/maintainability of your code, then there are deeper problems with your coding style that won't be solved by dragging "struct" around.

>Not typedef'ing your structs forces you to use extra 7 characters per type mention for no clear benefit. To put it differently - if NOT having "struct" in front of a type name has any effect on readability/maintainability of your code, then there are deeper problems with your coding style that won't be solved by dragging "struct" around.

The benefit is to readability. You should treat structs differently from scalars, and the code should make the distinction apparent. You should not generally, for example, pass structs by value. This is just laziness.

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.

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 and forth to the type definitions.

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

You can just use stdint types. Or is it really better to typedef a CUTE_INT?

That's not what I'm talking about. CUTE_INT is stupid, but maybe mylib_error makes sense. It depends on context.

There are also enums, which are user defined scalar types (although I don't think this fact really affects your argument).

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.

Why not pass structs by value?

Of course, it is copied because "by value". On the AMD64 architecture your compiler will transfer your little structs in registers.

I doubt getting confused between structs and scalars is a problem in practice. It surely never has been for me.

For me this is cargo cult maintainability: it has the sound of a good advice, but doesn't seem grounded in reality.

I have been writing C for more than a decade and have never been confused about whether or not a type was a strict or a scalar. This is a nonsense hypothetical.

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 functions (e.g. wrapper around fprintf for logging). And there is also the '_Generic' thing for people, who can use C11.

Another unavoidable use of macros is to convert symbolic names into string literals or to enable warnings for printf wrappers in a portable code.

As for include guards one has to look really hard [1] to get a compiler that does not support #pragma once.

[1] - https://en.wikipedia.org/wiki/Pragma_once#Portability

I think these are just basic general principles, not unbreakable rules. Keep them in mind but break them when you really have too. Like the quote at the beginning says, avoid doing stupid things, but don't refrain from doing clever things when you have to.

For somethings like setting up boards, typedef is sometimes required too; or at least that is what I was told in my class xD

Also, typedef make things like arrays of function pointers much easier to read.

It all depends on the level. array of pointers to func to array of structs X , yes. struct X, no.

Reply on news.ycombinator.com