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.