3 ms·

Probably the 1e6th approach, but anyway, I also wanted to play with this myself: here's a _Generic and macro based approach to get printf type-safe in C. It ne

Probably the 1e6th approach, but anyway, I also wanted to play with this myself: here's a _Generic and macro based approach to get printf type-safe in C. It needs C11, and uses some gcc extensions.

marcodiego 5y ago
I, a few times, got reasonably far implementing a generic, type-safe, variadic, macro-based and using _Generic "print" for C. I copied some examples of how to implement variadic macros, and expanded on that for C basic types. It mostly worked, you'll always have difficulty for corner cases like separating pointers and arrays, but it worked well for the basic C types. I gave up for a few reasons: - I wanted a form to register new types, so it could work for user-defined types; - the C pre-processor knows nothing about lists that can be expanded multiple times; - variadic C macros are ugly hacks. Maybe one day I'll get back to it and publish it. The interesting part is that _Generic combined with macros allows some very interesting tools for implementing primitive forms of polymorphism. Actually, if the C pre-processor supported lists, it would be possible to implement RTTI in C.
- bumblebritches5 5y ago
  > - I wanted a form to register new types, so it could work for user-defined types; > - the C pre-processor knows nothing about lists that can be expanded multiple times; I'm actually working on both features as Clang extensions. #repeat, a preprocessor directive to loop, can be combined with _Pragma(push_macro/pop_macro) to create lists by redefining a macro. and currently #increment, though I think I want to expand on this so that other macros can be redefined more easily to create lists via push/pop macro. The reason push_macro/pop_macro pragmas can't work, is the macro has to be undefined and redefined, and the value then pushed onto a stack in the compiler. and you can't redefine a macro in the body of another macro directly. so I've been thinking about maybe a _Pragma(redefine_macro(MacroToRedefine, NewValueForRedefinedMacro)) but I don't want it to be limited to the _Pragma area of the compiler, I want it to be eventually standardized. I've been talking to a friend at WG14 who suggested making it a "Preprocessor Expression, like `__has_c_attribute` and `defined()` So that's the area I've been working on recently for the Increment/Redefine PE lately.
  - bumblebritches5 5y ago
    As for _Pragma(redefine_macro()) I don't want it to be a pragma, is the problem. I want it to be either a compile-time operator like sizeof, or a Preprocessor Expression so it can be used correctly. and it would eclipse #increment pretty easily; __redefine_macro(MacroNameToRedefine, ReplacementExpression) if ReplacementExpression is a macro identifier it would be expanded first, so like `MacroToRedefine + 1` should work, I see no reason it shouldn't work. maybe it would be ugly, but I think it would work. ---- My motivation is compile time registration for codecs, test suites, test cases being registered to suites, etc.
  - marcodiego 5y ago
    I spent a long time thinking about this. My conclusion is that the simplest way to achieve this, at least in GCC, is to create a #copy directive that allows a macro, together with its stack, to be copied to another. GCC already allows stack expansion with push and pop but it can only be expanded once; the #copy directive would fix that. If you get anything close to that working, that would be a godsend. It is the last remaining piece of the puzzle for me to implement complete RTTI in C. It would certainly help to minimize glib boiler plate code too. I'd really like it to be part of c2x, but I think it is too late now. If it is implemented by either GCC or Clang, the remaining other would certainly it too since it is too useful. So getting it to work in any of these would be good enough for me. How can I track/follow your progress?
    - bumblebritches5 5y ago
      Yeah, C2x is no longer accepting new proposals at all. Today was the last day for previously-proposed updates, and December 1st was the deadline for new proposals. I got my proposal for Unicode Length Modifiers in on time, but I don't know if it's been accepted yet. As for LLVM, I am just an unemployed dude, but I have a fork of LLVM on my github I push to while testing, but I am new to the Clang codebase so it's slow going. I don't want to say my username publicly tho, is there a way to PM here?
  - tinkersleep 5y ago
    There is __VA_OPT__ in C++2a, which handles recursion termination in macro expansion. This will probably be in future C, too, right? And if there was also __EVAL__ to force the macro preprocessor into another evaluation level, you could write recursive macros quite easily, e.g., to wrap every argument into a function call: #define EACH(f,x,...) f(x) __VA_OPT__(, __EVAL__(EACH(f, __VA_ARGS__))) This would make the macro magic for this library trivial: you could process lists recursively. Edit: added missing paren
- tinkersleep 5y ago
  > - I wanted a form to register new types, so it could work for user-defined types; Yes, I had the same urge. You can easily fall into the trap of too many features on the list. I settled on keeping user types out: you can always write a stringify() and pass that to the printf. Not the same, I know. But a more finite project. > - the C pre-processor knows nothing about lists that can be expanded multiple times; Yeah, that's a hack. Look at the 'VA_EXP()' macros in include/va_print/base.h. Ugly. Incomprehensible. > - variadic C macros are ugly hacks. Absolutely. But I think there is no other way in C. > Actually, if the C pre-processor supported lists, it would be possible to implement RTTI in C. I couldn't resist to put in '%t' which prints the C type of the argument...
- 95014_refugee 5y ago
  __attribute__((overloadable)) is also worth looking at...
  - marcodiego 5y ago
    Hm… interesting… it would be good if GCC supported it too.
kzrdude 5y ago
Do you have a usage example? One early in thee readme maybe. Seeing is believing

Probably the 1e6th approach, but anyway, I also wanted to play with this myself: here's a _Generic and macro based approach to get printf type-safe in C. It needs C11, and uses some gcc extensions.

marcodiego 5y ago

I, a few times, got reasonably far implementing a generic, type-safe, variadic, macro-based and using _Generic "print" for C. I copied some examples of how to implement variadic macros, and expanded on that for C basic types. It mostly worked, you'll always have difficulty for corner cases like separating pointers and arrays, but it worked well for the basic C types. I gave up for a few reasons: - I wanted a form to register new types, so it could work for user-defined types; - the C pre-processor knows nothing about lists that can be expanded multiple times; - variadic C macros are ugly hacks. Maybe one day I'll get back to it and publish it. The interesting part is that _Generic combined with macros allows some very interesting tools for implementing primitive forms of polymorphism. Actually, if the C pre-processor supported lists, it would be possible to implement RTTI in C.

bumblebritches5 5y ago
> - I wanted a form to register new types, so it could work for user-defined types; > - the C pre-processor knows nothing about lists that can be expanded multiple times; I'm actually working on both features as Clang extensions. #repeat, a preprocessor directive to loop, can be combined with _Pragma(push_macro/pop_macro) to create lists by redefining a macro. and currently #increment, though I think I want to expand on this so that other macros can be redefined more easily to create lists via push/pop macro. The reason push_macro/pop_macro pragmas can't work, is the macro has to be undefined and redefined, and the value then pushed onto a stack in the compiler. and you can't redefine a macro in the body of another macro directly. so I've been thinking about maybe a _Pragma(redefine_macro(MacroToRedefine, NewValueForRedefinedMacro)) but I don't want it to be limited to the _Pragma area of the compiler, I want it to be eventually standardized. I've been talking to a friend at WG14 who suggested making it a "Preprocessor Expression, like `__has_c_attribute` and `defined()` So that's the area I've been working on recently for the Increment/Redefine PE lately.
- bumblebritches5 5y ago
  As for _Pragma(redefine_macro()) I don't want it to be a pragma, is the problem. I want it to be either a compile-time operator like sizeof, or a Preprocessor Expression so it can be used correctly. and it would eclipse #increment pretty easily; __redefine_macro(MacroNameToRedefine, ReplacementExpression) if ReplacementExpression is a macro identifier it would be expanded first, so like `MacroToRedefine + 1` should work, I see no reason it shouldn't work. maybe it would be ugly, but I think it would work. ---- My motivation is compile time registration for codecs, test suites, test cases being registered to suites, etc.
- marcodiego 5y ago
  I spent a long time thinking about this. My conclusion is that the simplest way to achieve this, at least in GCC, is to create a #copy directive that allows a macro, together with its stack, to be copied to another. GCC already allows stack expansion with push and pop but it can only be expanded once; the #copy directive would fix that. If you get anything close to that working, that would be a godsend. It is the last remaining piece of the puzzle for me to implement complete RTTI in C. It would certainly help to minimize glib boiler plate code too. I'd really like it to be part of c2x, but I think it is too late now. If it is implemented by either GCC or Clang, the remaining other would certainly it too since it is too useful. So getting it to work in any of these would be good enough for me. How can I track/follow your progress?
  - bumblebritches5 5y ago
    Yeah, C2x is no longer accepting new proposals at all. Today was the last day for previously-proposed updates, and December 1st was the deadline for new proposals. I got my proposal for Unicode Length Modifiers in on time, but I don't know if it's been accepted yet. As for LLVM, I am just an unemployed dude, but I have a fork of LLVM on my github I push to while testing, but I am new to the Clang codebase so it's slow going. I don't want to say my username publicly tho, is there a way to PM here?
- tinkersleep 5y ago
  There is __VA_OPT__ in C++2a, which handles recursion termination in macro expansion. This will probably be in future C, too, right? And if there was also __EVAL__ to force the macro preprocessor into another evaluation level, you could write recursive macros quite easily, e.g., to wrap every argument into a function call: #define EACH(f,x,...) f(x) __VA_OPT__(, __EVAL__(EACH(f, __VA_ARGS__))) This would make the macro magic for this library trivial: you could process lists recursively. Edit: added missing paren
tinkersleep 5y ago
> - I wanted a form to register new types, so it could work for user-defined types; Yes, I had the same urge. You can easily fall into the trap of too many features on the list. I settled on keeping user types out: you can always write a stringify() and pass that to the printf. Not the same, I know. But a more finite project. > - the C pre-processor knows nothing about lists that can be expanded multiple times; Yeah, that's a hack. Look at the 'VA_EXP()' macros in include/va_print/base.h. Ugly. Incomprehensible. > - variadic C macros are ugly hacks. Absolutely. But I think there is no other way in C. > Actually, if the C pre-processor supported lists, it would be possible to implement RTTI in C. I couldn't resist to put in '%t' which prints the C type of the argument...
95014_refugee 5y ago
__attribute__((overloadable)) is also worth looking at...
- marcodiego 5y ago
  Hm… interesting… it would be good if GCC supported it too.

kzrdude 5y ago

Do you have a usage example? One early in thee readme maybe. Seeing is believing