But apart from that, you have to consider what the alternatives would be before dissing it (which doesn't imply that I think every single remaining macro is altogether nice and tidy, though). For e.g. block_alloc and fsort, I can only think of C++ templates as being able to improve it in any way.
Writing our own preprocessor has been a success for modules, so perhaps that is also a possible way to go here.
/ Martin Nilsson (räfsfiskal)
Previous text:
2004-05-18 23:51: Subject: Re: Nettle cmod segfault
I think, like many others, that there are too complex macros in Pike and that it's a big problem for code readibility.
I guess you're talking of things like the block_alloc system, fsort.h, the volymous macros for doing string stuff once for each string width, and the undisputed king of the hill: The interpret_functions.h macro system. Things like THREADS_DISALLOW is just an ordinary macro and can hardly be considered a readability problem.
I know what you mean; I got fairly frustrated too the first time I tried to grep through the source for the definition of get_marker and couldn't find it anywhere. Still, once you've groked how it works it's damn handy.
Some of the string processing stuff could probably have been written without macros and instead accept the performance hit, and it got to be possible to clean up the interpret_functions.h stuff somehow. Using macros to at compile time choose between a heap of separate functions and a giant case is a bit over the edge imho; trusting function inlining just a little would have made it a lot simpler.
But apart from that, you have to consider what the alternatives would be before dissing it (which doesn't imply that I think every single remaining macro is altogether nice and tidy, though). For e.g. block_alloc and fsort, I can only think of C++ templates as being able to improve it in any way.
/ Martin Stjernholm, Roxen IS