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