3 ms·

Is making so much use of macros for code generation really suggested practice in C? It seems like it would be difficult to debug.

by slimsag 12y ago

doomrobo 12y ago
I think that macros are the only real option if you want to have an interface for multiple types and still have some semblance of type-safety. The only alternative I can think of is writing code that takes void* everywhere.
- faragon 12y ago
  Yes. But the "void *" everywhere code would take just a portion of the space, as for every different type, you would be duplicating the code.
- tbirdz 12y ago
  There is also the approach used for linked lists in the Linux Kernel: http://kernelnewbies.org/FAQ/LinkedLists http://kernelnewbies.org/FAQ/LinkedLists
- zem 12y ago
  the third option is to write your code in some more type-safe language (heck, even c++) and add extern c wrappers around all your exposed functions.
ori_b 12y ago
No, it isn't. Most C will use void* instead. Which approach is better is left as an exercise.
duaneb 12y ago
Someone who's used macros before extensively— Macros are only unreadable if they're written that way. See, while C can be confusing, it's built using simple tools—you can use the c preprocessor apart from the compiler itself. By default, c without cpp is not pre-processed, so you have entire control of the output. (many OS's cc/libc implementations make extensive use of macros, e.g. assert, hence my "default" qualification). Writing with this in mind would allow two layers of compilation—once to verify the pre-processor, once to verify the resulting c compilation. While it is annoying, it doesn't require any more skill than a write-compile-debug loop.
koenigdavidmj 12y ago
There are plenty of systems where errno is #define'd to a more complex expression in order to provide per-thread errors. From glibc's bits/errno.h on Linux: # ifndef __ASSEMBLER__ /* Function to get address of global `errno' variable. */ extern int *__errno_location (void) __THROW __attribute__ ((__const__)); # if !defined _LIBC || defined _LIBC_REENTRANT /* When using threads, errno is a per-thread value. */ # define errno (*__errno_location ()) # endif # endif /* !__ASSEMBLER__ */ #endif /* _ERRNO_H */ I wouldn't expect it to be common to see a macro with parameters being an lvalue, though. It wouldn't phase a C++ programmer, since references make it possible and even idiomatic to return lvalues. Where you normally see this is: x["foo"] = "bar"; is just syntactic sugar for // operator[] could be any "normal" function name! x.operator[]("foo") = "bar";
yoklov 12y ago
No. There are 4-5 common approaches. - Macros, as you see. - Writing a generic implementation that takes a void* (or suitable "any" type). This has many, many drawbacks... no type safety, poor performance, frequently requires allocations if you want to store more than sizeof(void), forces the compiler to generate poor code... - Custom data structures for your use-case. In my experience, this is the most common for performance-critical code. Doesn't end up being a problem nearly* as often as some people think (e.g., you don't spend much time writing data structure code), as you only write the subset for what you actually need at the time (A hash-table is fairly easy if you only need get-or-insert, exists, and clear), and you don't tend to need these data structures as much as you might think. This is still not ideal for some applications that require many containers (this is the minority of all applications, in my experience!). - Intrusive containers. This only works in some cases (lists, trees, and chained hash tables), but basically the idea is that you put the shared part of the data structure as a struct at the front (or in the middle if the implementation does some offsetof math) of your type, and then all the operations use that. This tends to be less than ideal because of both the pointer chasing and storing additional pointers, but it beats the void* approach, and is better than poor implementations of the others, assuming you can do the data structure you want this way. - Writing code that generates the code for the container for each type you need. This isn't as common as the other three but you definitely see it. Typically after generating it once it's customized but sometimes the ability to edit the generator and re-generate it might take priority.

Is making so much use of macros for code generation really suggested practice in C? It seems like it would be difficult to debug.

by slimsag 12y ago

Is making so much use of macros for code generation really suggested practice in C? It seems like it would be difficult to debug.

doomrobo 12y ago

I think that macros are the only real option if you want to have an interface for multiple types and still have some semblance of type-safety. The only alternative I can think of is writing code that takes void* everywhere.

faragon 12y ago
Yes. But the "void *" everywhere code would take just a portion of the space, as for every different type, you would be duplicating the code.
tbirdz 12y ago
There is also the approach used for linked lists in the Linux Kernel: http://kernelnewbies.org/FAQ/LinkedLists http://kernelnewbies.org/FAQ/LinkedLists
zem 12y ago
the third option is to write your code in some more type-safe language (heck, even c++) and add extern c wrappers around all your exposed functions.

ori_b 12y ago

No, it isn't. Most C will use void* instead. Which approach is better is left as an exercise.

duaneb 12y ago

Someone who's used macros before extensively— Macros are only unreadable if they're written that way. See, while C can be confusing, it's built using simple tools—you can use the c preprocessor apart from the compiler itself. By default, c without cpp is not pre-processed, so you have entire control of the output. (many OS's cc/libc implementations make extensive use of macros, e.g. assert, hence my "default" qualification). Writing with this in mind would allow two layers of compilation—once to verify the pre-processor, once to verify the resulting c compilation. While it is annoying, it doesn't require any more skill than a write-compile-debug loop.

koenigdavidmj 12y ago

There are plenty of systems where errno is #define'd to a more complex expression in order to provide per-thread errors. From glibc's bits/errno.h on Linux: # ifndef __ASSEMBLER__ /* Function to get address of global `errno' variable. */ extern int *__errno_location (void) __THROW __attribute__ ((__const__)); # if !defined _LIBC || defined _LIBC_REENTRANT /* When using threads, errno is a per-thread value. */ # define errno (*__errno_location ()) # endif # endif /* !__ASSEMBLER__ */ #endif /* _ERRNO_H */ I wouldn't expect it to be common to see a macro with parameters being an lvalue, though. It wouldn't phase a C++ programmer, since references make it possible and even idiomatic to return lvalues. Where you normally see this is: x["foo"] = "bar"; is just syntactic sugar for // operator[] could be any "normal" function name! x.operator[]("foo") = "bar";

yoklov 12y ago

No. There are 4-5 common approaches. - Macros, as you see. - Writing a generic implementation that takes a void* (or suitable "any" type). This has many, many drawbacks... no type safety, poor performance, frequently requires allocations if you want to store more than sizeof(void), forces the compiler to generate poor code... - Custom data structures for your use-case. In my experience, this is the most common for performance-critical code. Doesn't end up being a problem nearly* as often as some people think (e.g., you don't spend much time writing data structure code), as you only write the subset for what you actually need at the time (A hash-table is fairly easy if you only need get-or-insert, exists, and clear), and you don't tend to need these data structures as much as you might think. This is still not ideal for some applications that require many containers (this is the minority of all applications, in my experience!). - Intrusive containers. This only works in some cases (lists, trees, and chained hash tables), but basically the idea is that you put the shared part of the data structure as a struct at the front (or in the middle if the implementation does some offsetof math) of your type, and then all the operations use that. This tends to be less than ideal because of both the pointer chasing and storing additional pointers, but it beats the void* approach, and is better than poor implementations of the others, assuming you can do the data structure you want this way. - Writing code that generates the code for the container for each type you need. This isn't as common as the other three but you definitely see it. Typically after generating it once it's customized but sometimes the ability to edit the generator and re-generate it might take priority.