Re: [boost] ScopeExit Review ends tomorrow

From: Tom Brinkman (reportbase_at_[hidden])
Date: 2007-08-22 18:14:36

> No. I fear that this macro, along with the "FOR_EACH" macro, that
> boost developers are warming up to "macros" in general. We should
> stick to standard syntax, even if the standard syntax is verbose and
> ugly. Macros always come back to bite you. My no vote is sole
> based on my dislike of macros. Macros internal to a library are
> fine, but for a public interface, I'm not persuaded.

>> I disagree with that in just about every way; it seems like the worst
>> kind of FUD, and it's factually inaccurate to boot.

Dave, your feelings about "macros" are well known. Your MPL library,
which I use, and your book, which I have purchased, have made
an important contribution to the C++ community.

However, If I have one criticisism, its your overuse and dependence
on macros.  Neverthless, if they are hidden in the library, and I as a user
dont have to see or know about them, I could care less.  That is,
unless, I was the unfortunate soul that had to maintain a library that
had many internal macros.

>> Boost developers in general have been warm to "macros" ever since
>> BOOST_STATIC_ASSERT, which was one of the very first public
>> Boost library components.

I stand corrected, as you say, boost developers have
always generally been "warm" to macros.

>> use macros *extensively* throughout many libraries, and, when
>> appropriate, in library interfaces. In nine years they haven't "come
>> back to bite us.

Couldn't disagree with your point more here.  The boost libraries that are
full of macros are very difficult to maintain and extend for all but the
original library authors.

If the boost developers suddenly retired,
who will maintain those libraries that make extensive use
of macros.  That could come back to bite the users if in
in the years ahead, the original library author has moved on. Not
saying that will happen, but its a concern of mine, and keeps
me from becoming to dependent on those libraries.

>> I think that in many cases have shown themselves to be
>> superior to any available alternative.

Also I disagree here as well.  BOOST_STATIC_ASSERT is one
of a few macros that you could argue that should be included
as public interface of boost.   I suspect that If we were study this
issue in depth, there would be very few examples of "public" macros
that would be superior to their alternatives.

"Non-public" internal macros,
shur, the library author should be allowed to explore the creative
use of macros all they want.