4 ms·
You can get better properties by using the include itself to do the macro expansion, e.g. #define VECTOR_TYPE int #include “vector.h” This will let you step i
by variadix 2y ago
You can get better properties by using the include itself to do the macro expansion, e.g.
#define VECTOR_TYPE int
#include “vector.h”
This will let you step into the macro generated functions in GDB and doesn’t require putting the function creation in macros (no backslashes, can write the implementations like normal code)
You can also get syntax like this that way
Vector_Push(int)(&vec, 1);
Which imo does a better job distinguishing the type from the name
- david2ndaccount 2y agoI wrote a blogpost describing this technique. https://www.davidpriver.com/ctemplates.html https://www.davidpriver.com/ctemplates.html
- eqvinox 2y agoI agree that the debugging and maintenance experience is much better that way, but it comes at the cost of very poor "DX". We, discussing this here on this thread, understand what's going on. But sadly at least for the projects I'm involved in, the average developer does not. TBH, rather than fancy high-meta generic support, I'd be much more appreciative of ISO C adding something like "_Include" to the preprocessor, e.g. #define DEFINE_MY_WRAPPER(foo, bar) _Include("wrapper.h") /* "foo", "bar" remain accessible in wrapper.h */ I tried implementing this in GCC but didn't get very far, it runs a bit counter to how includes are handled currently. P.S.: I ended up doing this https://github.com/FRRouting/frr/pull/15876/files#diff-907836b27aed5047e0e2db06b6f235b8f2630e11411c5b857125cd190872da8fR6-R12 https://github.com/FRRouting/frr/pull/15876/files#diff-90783... instead; a tool that can be invoked to expand some DEFINE_FOO if needed for debugging. It's not used particularly often, though.