4 ms·

> macros can’t be debugged. When you use a function, that function can be stepped through by the debugger. The macro cannot. Looks like the debugger could use

> macros can’t be debugged. When you use a function, that function can be stepped through by the debugger. The macro cannot. Looks like the debugger could use some improvement. > A macro is faster than a function. This is false. Macros may be faster in some cases, but I've seen them being slower. I suspect this is because functions have more type information that can help the optimiser. I've tried it with Monocypher: replacing serialisation/de-serialisation functions (load and store) by equivalent macros slowed the whole thing down.

deleted 9y ago
[deleted]
dangerbird2 9y ago
Also, C99 `inline` functions calls do not neccessarily compile to inlined code, and non-inline functions may or may not be inlined, and in certain cases (most notably tail-call optimizations), will not create new stack frames.
manwe150 9y ago
> Looks like the debugger could use some improvement. Try `gcc -g3` (the default is 2). But because C-style macros are context-sensative string operations, the result is not necessarily especially pleasant/useful and can be rather large (slowing down the debugger for everything else). I find that using `static inline` functions and `static const` variables in the header can just be much nicer to work with all around (some argument type-checking, better stack frame management means alloca is usable, no accidental syntax clashes requiring lots of extra parens to avoid, and real debug info). And, if necessary, use a tiny macro just to form the call to the real function or form the declarations for repeated tabular data. I wouldn't have expected macros to be slower in any case, however.
- loup-vaillant 9y ago
  > I wouldn't have expected macros to be slower in any case, however. Neither did I to be honest. I was searching for low hanging fruits, and forcing inlining with macros looked made some kind of sense. I expected the compiler to generate the same code, yet somehow it didn't.

deleted 9y ago

[deleted]

dangerbird2 9y ago

Also, C99 `inline` functions calls do not neccessarily compile to inlined code, and non-inline functions may or may not be inlined, and in certain cases (most notably tail-call optimizations), will not create new stack frames.

manwe150 9y ago

> Looks like the debugger could use some improvement. Try `gcc -g3` (the default is 2). But because C-style macros are context-sensative string operations, the result is not necessarily especially pleasant/useful and can be rather large (slowing down the debugger for everything else). I find that using `static inline` functions and `static const` variables in the header can just be much nicer to work with all around (some argument type-checking, better stack frame management means alloca is usable, no accidental syntax clashes requiring lots of extra parens to avoid, and real debug info). And, if necessary, use a tiny macro just to form the call to the real function or form the declarations for repeated tabular data. I wouldn't have expected macros to be slower in any case, however.

loup-vaillant 9y ago
> I wouldn't have expected macros to be slower in any case, however. Neither did I to be honest. I was searching for low hanging fruits, and forcing inlining with macros looked made some kind of sense. I expected the compiler to generate the same code, yet somehow it didn't.