4 ms·

Meh, you just need more macros ... https://gitlab.com/nbdkit/nbdkit/-/blob/296b9dd041fdbcbaa73119db1ff58c5e115cc9b8/common/utils/vector.h#L112 https://gitlab.c

by rwmj 2y ago

Meh, you just need more macros ... https://gitlab.com/nbdkit/nbdkit/-/blob/296b9dd041fdbcbaa73119db1ff58c5e115cc9b8/common/utils/vector.h#L112 https://gitlab.com/nbdkit/nbdkit/-/blob/296b9dd041fdbcbaa731...

eqvinox 2y ago
<300 lines? Peanuts! ;D https://github.com/FRRouting/frr/blob/master/lib/typesafe.h https://github.com/FRRouting/frr/blob/master/lib/typesafe.h https://docs.frrouting.org/projects/dev-guide/en/latest/lists.html https://docs.frrouting.org/projects/dev-guide/en/latest/list...
naasking 2y ago
That monomorphizes every definition, and the point of this proposal was to avoid that.
- rwmj 2y ago
  That's true, although I wonder if a "sufficiently smart compiler" could combine compatible definitions. Also note it's in a header file and most of these functions are minimal enough they would be inlined.
  - eqvinox 2y ago
    I'd distinguish here and not label one-liner "cast wrappers" as monomorphization. And then you can in fact do a lot with macros. (My definition of a "cast wrapper" is: function body contains exactly one function call, mostly forwarding arguments. Pointer offsets¹ on arguments/retval are allowed, as well as adding sizeof/offsetof/constant integer arguments, but nothing else.) ¹ this may include some conditionals to keep NULL as NULL when applying a pointer offset. I would expect the compiler to be able to optimize these away in 99% of cases, but TBH I don't care if it doesn't and I'm littering a bunch of small wrapper functions.
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 ago
  I wrote a blogpost describing this technique. https://www.davidpriver.com/ctemplates.html https://www.davidpriver.com/ctemplates.html
- eqvinox 2y ago
  I 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.

by rwmj 2y ago

eqvinox 2y ago

<300 lines? Peanuts! ;D https://github.com/FRRouting/frr/blob/master/lib/typesafe.h https://github.com/FRRouting/frr/blob/master/lib/typesafe.h https://docs.frrouting.org/projects/dev-guide/en/latest/lists.html https://docs.frrouting.org/projects/dev-guide/en/latest/list...

naasking 2y ago

That monomorphizes every definition, and the point of this proposal was to avoid that.

rwmj 2y ago
That's true, although I wonder if a "sufficiently smart compiler" could combine compatible definitions. Also note it's in a header file and most of these functions are minimal enough they would be inlined.
- eqvinox 2y ago
  I'd distinguish here and not label one-liner "cast wrappers" as monomorphization. And then you can in fact do a lot with macros. (My definition of a "cast wrapper" is: function body contains exactly one function call, mostly forwarding arguments. Pointer offsets¹ on arguments/retval are allowed, as well as adding sizeof/offsetof/constant integer arguments, but nothing else.) ¹ this may include some conditionals to keep NULL as NULL when applying a pointer offset. I would expect the compiler to be able to optimize these away in 99% of cases, but TBH I don't care if it doesn't and I'm littering a bunch of small wrapper functions.

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 ago
I wrote a blogpost describing this technique. https://www.davidpriver.com/ctemplates.html https://www.davidpriver.com/ctemplates.html
eqvinox 2y ago
I 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.