Re: [boost] ScopeExit Review ends tomorrow

From: David Abrahams (dave_at_[hidden])
Date: 2007-08-22 19:06:16

on Wed Aug 22 2007, "Tom Brinkman" <reportbase-AT-gmail.com> wrote:

> Dave, your feelings about "macros" are well known. 

They are?  I don't have strong feelings about "macros;" they're just a
tool.

> If I have one criticisism, its your overuse and dependence on
> macros.

What can I learn from your criticism?  What is it based on other than
the fact that you don't like macros?  By what standard shall we decide
that use is "overuse?"

>>> 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.

Well, let's be clear.  We've been "warm" in the sense that we're
willing to use macros when they are the best solution to a problem.

>>> 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.

How has that bitten us?

> 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.

One could say that for any programming paradigm that isn't "in the
mainstream," which is an entirely relative judgement.  Certainly
Boost's "dependence on and overuse of templates" is often cited by
those unfamiliar with certain programming styles as presenting exactly
the same danger.  At Oracle, they use C and ban C++ for the same
reasons.
 
>>> 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.

Well, please study it in depth before leveling such a charge publicly
based on your suspicions.

I never reach for macros in interfaces as a first choice, but where I
have used them, they have made a transformative difference to the
quality of interface I can provide to my users.  I think the same
applies to Boost library authors across the board.  For one example,
BOOST_TYPEOF could not be done effectively without a public macro.
Also, Boost.Parameter acquired a very sophisticated macro system for
1.34.x (credit for that work mostly goes to Daniel Wallin) and it made
an enormous difference in how easy it is to write parameter-enabled
functions.  The macro generates all the boilerplate of forwarding
functions, handles the "forwarding problem" for the user, evaluates
defaults in exactly the lazy way one would like without requiring
lambdas or other function objects, avoids exposing ArgumentPacks, and
there are probably five more improvements I can't remember off the top
of my head.  The number of concepts one has to understand in order to
just write a parameter-enabled function has gone down by an order of
magnitude, and none of that would be possible without the use of
(pretty intense) macros in the library interface.

To compare the old interface with the new, compare
http://svn.boost.org/trac/boost/browser/tags/Version_1_33_1/boost/libs/parameter/doc/html/index.html?rev=38858&format=raw
and http://boost.org/libs/parameter
.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
The Astoria Seminar ==> http://www.astoriaseminar.com