\nI try not to rant, but it happens sometimes.\nThis time, I’m ranting on purpose: to complain about\nmacro-izing flow control.\n<\/p>\n
\nNo two people use the same macros, and\nwhen you see code that uses them you have to go\ndig through header files to figure out what they do.\n<\/p>\n
\nThis is particularly gruesome when you’re trying to\ndebug a problem with some code that somebody else wrote.\nFor example, say you see a critical section entered\nand you want to make sure\nthat all code paths out of the function release the\ncritical section. It would normally be as simple as\nsearching for “return” and “goto” inside the function body,\nbut if the author of the program hid those operations\nbehind macros, you would miss them.\n<\/p>\n
\nHRESULT SomeFunction(Block *p)\n{\n HRESULT hr;\n EnterCriticalSection(&g_cs);\n VALIDATE_BLOCK(p);\n MUST_SUCCEED(p->DoSomething());\n if (andSomethingElse) {\n LeaveCriticalSection(&g_cs);\n TRAP_FAILURE(p->DoSomethingElse());\n EnterCriticalSection(&g_cs);\n }\n hr = p->DoSomethingAgain();\nCleanup:\n LeaveCriticalSection(&g_cs);\n return hr;\n}\n<\/pre>\n\n[Update: Fixed missing parenthesis in code that was never\nmeant to be compiled anyway. Some people are so picky. – 10:30am]\n<\/p>\n
\nIs the critical section leaked?\nWhat happens if the BLOCK fails to validate?\nIf DoSomethingElse fails, does DoSomethingAgain get called?\nWhat’s with that unused “Cleanup” label?\nIs there a code path that leaves the “hr” variable\nuninitialized?\n<\/p>\n
\nYou won’t know until you go dig up the header file that\ndefined the VALIDATE_BLOCK, TRAP_FAILURE, and MUST_SUCCEED macros.\n<\/p>\n
\n(Yes, the critical section question could be avoided by\nusing a lock object with destructor, but that’s not my point.\nNote also that this function temporarily exits the critical section.\nMost lock objects don’t support that sort of thing,\nthough it isn’t usually that hard to add, at the cost of\na member variable.)\n<\/p>\n
\nWhen you create a flow-control macro, you’re modifying the language.\nWhen I fire up an editor on a file whose name ends in “.cpp” I expect\nthat what I see will be C++ and not some strange dialect\nthat strongly resembles C++ except in the places where it doesn’t.\n(For this reason, I’m pleased that C# doesn’t support macros.)\n<\/p>\n
\nPeople who still prefer flow-control macros should be\nsentenced to maintaining the original Bourne shell.\nHere’s a fragment:\n<\/p>\n
\nADDRESS\talloc(nbytes)\n POS\t nbytes;\n{\n REG POS\trbytes = round(nbytes+BYTESPERWORD,BYTESPERWORD);\n LOOP INT\t c=0;\n\tREG BLKPTR p = blokp;\n\tREG BLKPTR q;\n\tREP IF !busy(p)\n\t THEN WHILE !busy(q = p->word) DO p->word = q->word OD\n\t\tIF ADR(q)-ADR(p) >= rbytes\n\t\tTHEN\tblokp = BLK(ADR(p)+rbytes);\n\t\t IF q > blokp\n\t\t THEN blokp->word = p->word;\n\t\t FI\n\t\t p->word=BLK(Rcheat(blokp)|BUSY);\n\t\t return(ADR(p+1));\n\t\tFI\n\t FI\n\t q = p; p = BLK(Rcheat(p->word)&~BUSY);\n\tPER p>q ORF (c++)==0 DONE\n\taddblok(rbytes);\n POOL\n}\n<\/pre>\n\nBack in its day, this code was\nheld up as an example of “death by macros”, code that relied\nso heavily on macros that nobody could understand it.\nWhat’s scary is that by today’s standards, it’s quite tame.\n<\/p>\n