3 ms·

> So shouldn't the use of macros be reducible to ordinary code? No, because it's a matter of performance. To avoid code duplication, without macros, you use ro

> So shouldn't the use of macros be reducible to ordinary code? No, because it's a matter of performance. To avoid code duplication, without macros, you use routines. To get the same performance as with macros the compiler needs to inline them - which only works up to a certain point. If you can't compromise on performance (for example for HPC or low power purposes) you can't replace macros/templates with anything but copy pasting code.

asveikau 13y ago
I think you misinterpreted my comment, but that's OK. My comment was that OOP in C can be seen kind of like a question of API or ABI (a bit like COM in the Windows world). If you need to do what some would consider hacky things with macros, or stuff that is "not very OO", you still want to keep boundaries between compilation units and libraries clean, and OO-style constructs is a good way to get that done. The fact that you used a macro is an implementation detail that disappears once your code is compiled. However to your (to my eyes entirely tangential) comment about subrountines.. No, you can't do everything macros do in a subroutine. For instance you can't take the parameters and stringify them with #, you can't concatenate tokens with ##, you can't do funny things with braces or have a macro declare a bunch of static variables or code for you. You can't do the co-routine hack that btilly's link references (although it is very "out there"). This means you can do lots of interesting things with macros that you cannot with a function. These things can be abused but they can also make your code a lot simpler, shorter, easier to understand - and with the uglier parts constrained to a small amount of code. I don't see it as in conflict with OOP because it doesn't have to leak outside a single compilation unit or library.

3 ms·

> So shouldn't the use of macros be reducible to ordinary code? No, because it's a matter of performance. To avoid code duplication, without macros, you use ro

by m_mueller 13y ago

asveikau 13y ago
I think you misinterpreted my comment, but that's OK. My comment was that OOP in C can be seen kind of like a question of API or ABI (a bit like COM in the Windows world). If you need to do what some would consider hacky things with macros, or stuff that is "not very OO", you still want to keep boundaries between compilation units and libraries clean, and OO-style constructs is a good way to get that done. The fact that you used a macro is an implementation detail that disappears once your code is compiled. However to your (to my eyes entirely tangential) comment about subrountines.. No, you can't do everything macros do in a subroutine. For instance you can't take the parameters and stringify them with #, you can't concatenate tokens with ##, you can't do funny things with braces or have a macro declare a bunch of static variables or code for you. You can't do the co-routine hack that btilly's link references (although it is very "out there"). This means you can do lots of interesting things with macros that you cannot with a function. These things can be abused but they can also make your code a lot simpler, shorter, easier to understand - and with the uglier parts constrained to a small amount of code. I don't see it as in conflict with OOP because it doesn't have to leak outside a single compilation unit or library.