Yet more C abuse

[simont]

In two recent posts here, I've suggested moderately evil things to do with the C preprocessor, both on the same theme of defining a macro that can be used like a loop keyword by following its invocation with a statement or block of your choice.

Last week some further thoughts on the subject occurred to me, which were rather more comprehensive and also considerably more evil still. I think I've now taken that general idea to somewhere near the limit of its possibilities, by developing a general system of construction-kit macros that make it more or less feasible for people to develop custom loop types.

The result is far too long to fit in this post, so I've put it up on my website. For those with a strong stomach and an interest in metaprogramming or C abuse or both, I present ‘Metaprogramming Custom Control Structures in C’: http://www.chiark.greenend.org.uk/~sgtatham/mp/.

Comments

What's the vbKeyCode constant for the {ANY} key?

[hairyears]

Thank you: that's not nearly as horrible as I expected it to be...

...Said an Excel developer.

I work on two levels: what's an elegant solution in coding terms; and the ugly questions about how it's actually going to compile and run. The overriding concerns on planet Hairyears are clarity and ease of maintenance - if it was performance, it wouldn't be in VBA! - but sometimes, I need to know what I'm doing, and what's being done for me. And some of *that* is horrible, through and through.

Which in turn means that understanding loops is more than merely coding them, and further reading - like this stuff - is essential.

[gerald_duck]

You mention C++, but surely these shenanigans (fascinating in their twistedness though they may be) belong entirely in the land of C?

In the first place, C++ entirely solves the problem of tidying away resources that go out of scope in a rather more thorough way. And, for that matter, iterators allow non-standard behaviours to be packaged in a for-loop-friendly way. (Even more friendly for C++11's range-based for loops.)

In the second, the combination of exceptions and C++'s somewhat necessary prohibition on jumping past a non-trivial constructor or destructor invocation make the idiom unusable in some cases and dangerous in others.

[simont]

I mention C++ mostly because there exists at least one compiler which hasn't yet got round to supporting C99 – but that compiler does support C++. So if you're prepared to write code in the common subset of C99 and C++ (which mostly just means adding a few explicit casts from void *), then you can do this sort of thing even when one of the compilers you have to support is that one.

It's true, of course, that if you're writing a program that's actually allowed to use C++ features then you probably want to be doing an entirely different set of horrifying language abuses :-)

[andrewducker]

Thank you for 56 points:
http://news.ycombinator.com/item?id=3694938

[kehoea.livejournal.com]

We have a good number of macros that might benefit from this in XEmacs, most of them here. (https://bitbucket.org/xemacs/xemacs/src/0df3cedee9ac/src/lisp.h#cl-1984) (Not the sort of code your average C programmer is that comfortable with, I admit.) Other things are more of a priority at the moment, but I'll bookmark your paper. Thanks!

[simont]

Yes, I see what you mean! Though it looks to me as if most of those loops fit reasonably well into a for statement, with the only annoying part being the need to declare some variables up front. I don't know what XEmacs's portability requirements are, but if they include C89 then you might find that my trickery doesn't benefit you after all due to the one extra-C89 feature (bringing declarations into scope via for initialisers) not being available to you.