A rant against flow control macros

???????????? (2007-07-09) [JeffHung.Blog]

???????????? (2007-07-09) [JeffHung.Blog] — Mon, 09 Jul 2007 18:46:13 GMT

PingBack from http://www.jeffhung.net/blog/articles/jeffhung/952/

QQ by omerm () | LjSEEK.COM

QQ by omerm () | LjSEEK.COM — Sat, 23 Dec 2006 05:58:01 GMT

PingBack from http://www.ljseek.com/qq_52954724.html

omerm: QQ

omerm: QQ — Sat, 23 Dec 2006 05:57:58 GMT

PingBack from http://www.livejournal.com/users/omerm/55178.html

Engineering Technology » Blog Archive » Macros are bad.

Engineering Technology » Blog Archive » Macros are bad. — Mon, 17 Apr 2006 21:39:59 GMT

PingBack from http://engtech.wordpress.com/2006/04/14/w-cc-macros-are-bad/

re: A rant against flow control macros

Purplet — Tue, 11 Jan 2005 14:29:00 GMT

quote :
Macros are great. My only complaint against them is that nobody has added an extension to swallow up the first { or ; token that comes after the usage of the macro.

#define SOMETHING(A) do { something(A); } while(0)

it swallows the ; and works ok if used in loops, ifs, etc :)

re: A rant against flow control macros

Paul Spendlove — Tue, 11 Jan 2005 13:20:00 GMT

Michael Greer:
"C++ is very useful over C without dragging exceptions into the mix. Exceptions are an experiment which has gone awry. They're the new snake oil. They work well in functional languages since there aren't side effects to be rolled back. Even people who believe in RAII are rarely actually prepared to make every possible error control path actually have all the rollback necessary."

Michael, why not read Bjarne Stroustrup's "Appendix E" to the "C++ Programming Language (3rd ed)"? It puts forward the views of the designer of the language on exception safety. It has been freely available on the web for more than 4 years by now.

I think it's something you haven't read yet. Why? Because you refer to RAII taking effort to implement and involving "rollback". But RAII is actually quite easy to implement and has *nothing* to do with whether you offer rollback semantics.

As well as defining what RAII actually means in this document, Stroustrup also points out why exceptions were added to C++ - to deal with errors in object construction. There are alternative ways to deal with such errors (eg by providing a separate error-checked "init()" function). Stroustrup covers the alternatives, and explains why he finds exceptions superior. I find his arguments convincing. You are at liberty to differ, but it's surely worth at least checking out what Stroustrup has to say.

RAII is really not hard to do. It generally requires no more than a good reference-counted templated pointer - such classes are widely and freely available, eg from the boost project. You frequently don't need to roll back every single operation, you just need to recover back to some higher level. Generally, simply releasing resources on the way back up the call chain is completely sufficient. When you *do* need to group stuff together in a transaction, you create a transaction object whose destructor rolls back, and give it a scope surrounding the members of the transaction.

In conclusion, if people wish not to use C++ exceptions, it's up to them. But if they are going to talk about exceptions in C++ and use terms such as RAII, they'll be able to make their points more convincingly if they first read what the designer of the language has to say on the topic.

PS RAII = "Resource Acquisition Is Initialisation", for those who were wondering.

re: A rant against flow control macros

Memet — Tue, 11 Jan 2005 02:11:00 GMT

Micheal: I agree that hidden control flow is evil, but I also think cleanup code shouldn't be 'cleanup' code at all.
I think we would all agree that duplicate code is the worst evil of all, correct? Well, in an ideal OO world where initialization is aquisition (with all the corrollaries that apply), there should never be 'cleanup code'. In my opinion, cleanup code can _never_ not be duplicate code. Anything that goes out of scope should 'internally' do all operations it requires to free its resources (ie. execute its destructor). That has the advantage of localizing functionality. That also has the advantage of providing a language-wise transactional environment where I should not need to know what all possible exit paths are because the owners of the resources clean themselves up.

My favorite example of what I hate is creating an ATL ASP object using the wizard. This is the code that gets generated:
hr = lpContext->get_Request(&lpRequest);
if(FAILED(hr))
{ lpContext.Release();
return hr;
}

// Get Response Object Pointer
hr = lpContext->get_Response(&lpResponse);
if(FAILED(hr))
{ lpContext.Release();
lpRequest.Release();
return hr;
}

// Get Server Object Pointer
hr = lpContext->get_Server(&lpServer);
if(FAILED(hr))
{ lpContext.Release();
lpRequest.Release();
lpResponse.Release();
return hr;
}

// Get Application Object Pointer
hr = lpContext->get_Application(&lpApplication);
if(FAILED(hr))
{ lpContext.Release();
lpRequest.Release();
lpResponse.Release();
lpServer.Release();
return hr;
}// ad infinitum

Aside from the fact that the wizard generates object code but still uses functional cleanup (which I find weird), you can't seriously be advocating that this (cleanup as required) is good practice, can you?
With exceptions, and a properly OO model, hidden control flow becomes irrelevant as you don't need clean up anyways. It's only when you mix and match API and OOP that it becomes tricky, but that brings me back to my original post's point.

All in all though, I don't mean to drag you into a flame war about OOP and exceptions. My point is just that I personally find that C++ doesn't really help you or provide you with tools for dealing with method encapsulation in a way that avoids code duplication, and that was originally why I had said Macros were useful for.

re: A rant against flow control macros

AC — Mon, 10 Jan 2005 10:01:00 GMT

Michael Grier: I don't consider your IF_FAILED_GOTO_EXIT as a good practice. I guess you've debugged a lot of deep nested ifs, but that's also bad practice. Good code shouldn't be too nested. If you introduce some coding discipline, you can always do something like

void DoSomething( ...
if ( cond1 ) return;
someth1();
if ( cond2 ) return;
mainThing

etc. Instead the above code some people would produce two nested ifs, and when the "main thing" has any logic, there are more nestings, and the code is hard to follow. Making "early returns" has also good effect of looking (to me) more like mathematical expression where you first exclude trivial cases.

Very often, when I get the code from somebody else, and rewrite the "multiple nesting" to the above presented principle (anybody knows if there's some name for it) I easily discover that the original author didn't cover some cases. Multiple ifs make it hard to see uncovered cases. Using a lot of returns stimulates covering all the cases.

re: A rant against flow control macros

Michael Grier [MSFT] — Mon, 10 Jan 2005 05:59:00 GMT

Re: memet:

C++ is very useful over C without dragging exceptions into the mix. Exceptions are an experiment which has gone awry. They're the new snake oil. They work well in functional languages since there aren't side effects to be rolled back. Even people who believe in RAII are rarely actually prepared to make every possible error control path actually have all the rollback necessary.

The point of the other blog entry Raymond references is that:

a = b + c;

doesn't clearly have any control flow when in fact it may have 3 (or 2 more if you consider failures in destructors for temporaries which terminate the application to be control flow).

MUST_SUCCEED(Foo());

is not better. There's some statement of intent but it's not clear what the ramifications are. But then I've also seen this style:

check << Foo();
check << Bar();

is that clear either? No, and for the same reason. I forget where I saw this but the rationale given by the team was that it's an idiom used in their source and when you get used to it, it's clear.

My point here at the end is that this actually has nothing to do with the use of macros. Hidden control flow is bad. It causes a lot of errors.

If we can agree that all of:

if (FAILED(hr = Foo()) goto Exit;
if (FAILED(hr = Bar()) goto EXit;

and

if (SUCCEEDED(hr = Foo())) {
hr = Bar();
}
return hr;

and

IF_FAILED_GOTO_EXIT(Foo());
IF_FAILED_GOTO_EXIT(Bar());

are reasonably clear (assuming that the macros do the expected thing... do you verify that SUCCEEDED() does what you expect?) then we can have a more interesting debate about:

a. How important RAII is
b. When do you split functions vs. nest conditions

I think that RAII is very important and I further think that if you can adopt a reasonable style you can prevent arbitrary new functions created only because the previous style created artificial source bloat and statement nesting. I like the use of macros because except for the annoying extra text on each source line, you get control flow that looks very much like the "exception-based ideal".

(I alluded to this but on my team when we started a recent project, we didn't mandate use of the error checking macros. So what happened? A lot of little error-path-cleanup code snippets occurred which of course didn't get all the error paths covered. Thus we decided to disallow the explicit checks and "goto Exit;".)

re: A rant against flow control macros

Memet — Sat, 08 Jan 2005 04:20:00 GMT

(Sigh, I just lost my entire post, I'm retyping)

Kent Boogaart:
The reason why we've opted to use macros across the project is because we wanted a unified exception handling system.
What that means is that any exception thrown in a particular system should be a well known exception, preferably derived from a base class. So the macros handle either defined program failures, or catch all failures (which generally indicate there was a problem that we didn't account for - which is bad).
Also, exceptions aren't meant to be used as control flow logic, they are meant to interrupt normal flow because something serious has occured.
A good example is std::map::find() which returns std::map::end() if it can't find the required element, it does *not* raise an exception. So it is wrong to compare exceptions to code like this:
hr = SomeOperation();
if( FAILED( hr ) )
hr = DoSomeOtherOperation();
else
hr = DoSomethingCool();

Here, we have a clear case of flow control based on the outcome of some function. On the other hand, operations like 'new' need to be atomic from a syntactic perspective, and not raising an exception when a object fails instantiation is not an option.
In the same vein, in the project we're in, components do not raise exceptions when their output is not something that cannot be recovered from, but when it is they do. And at that point, having a unified exception handling architecture really gives cohesion to the system since now you can log what's happening in the app using, for example, a single point of logging in your base exception class.

Michael Grier:
The problem is not that we are in a blissful state of denial, it's that C++ needs exceptions to be robust. C++ classes could not be instantiated properly without exceptions. When that observation sets in, you are faced with either using C++ as an enhanced C syntax compiler, and using COM (or something else) as your object model, or using C++ as an object oriented language and interfacing with COM as you would with any other C API. Even the #import code generates _com_error exceptions when wrapping around COM objects. It's just a matter of principle, and for those who want to use C++ as an OOP, then exceptions are the way to go.

(I'm sure I forgot to say something from what I had originally written, ah well)