It is simpler but also prone to errors that the do-while(false) method is isn't. The do-while(false) method requires a semicolon to work, while it is optional and can silently change the behavior of your code whether it is there or not with your variant.

I used to do it simpler...

#define CheckPrecondition(condition) { if ( ! condition) goto ON_PRECONDITION_FAIL; }

Could have sworn I used to get that to work in a (native code) FSM macro simplified script language

But, I'd say that such hacks deserves some happy debugging times when they do change the behavior...

It was used within an all 'scripted' code block setting (FSMs for object behaviors) where the rest of the mini-language macros were used of similar definitions (and were not interwoven with normal code). That language statement defines actually would look more like :

#define PRECOND(CONDX) { if ( ! CONDX) goto STATEX##PRECOND_FAIL; }

The more interesting defines were for the FSM state wrappers to work within a BIG SWITCH. and the ones needed to break each behavior state into 3 seperately run behavioral phases of the game loop. There could be competing tasks for each object state, which required seperated out phase processing (by tasks and individual target factors) : first - discovery via state-task specialized sensor searches and situation conditions, then second - a phase prioritizing the search results , picking a 'best' task and executing the corresponding actions for the task, third - a epilog phase which did evaluations and state transitions based on results.

Much of the overall complexity came from having interacting objects be frozen for equal evaluation, and after priority selection both objects being locked into an interaction mode (locking out other object's interactions and forcing wait time for the duration of the action (related to the animation time).

The whole thing was organized to be table form programming (but was compiled into native code). It had shortcomings of only being able to handle rudimentary inter-object interactions and signalling before becoming cumbersome. I had to shift more complex object AI operations to a Planner type scheme (easier to handle interupted tasks when you just abandon and reevaluate everything and restart). The original mechanism was retained for objects with simple reactionary and single minded behaviors as it was more lightweight and was still used on a majority of objects in the simulation.

The script code using such macro statments were not nested (eliminated most of any problematic cases) and quite regular in the way they were used (and so easy to spot any syntax mistakes). So there were few problems of that type.

The debugging fun was actually in the intricacies of the inter-object behavior interactions with follow-on sequential states for many tasks (I was considering building a wizard to help streamline the creation of the script 'code' data to handle alot of the table building 'bookkeeping'....)