As the only one who is watching on the github repository, I'm interesting in this library and had implemented some similiar pattern and used in my own projects based on ANSI C: https://github.com/zhouzhenghui/c-sigslot/tree/master/src/preprocessor In fact, my implementation was inspired very much by Edward's library, as well as Paul Mensonides's chaos-pp library <http://sourceforge.net/projects/chaos-pp/> and Jens Gustedt's P99 library <http://gustedt.wordpress.com/>, the difference is that I just rewrote certain features in a simple and straightforward way. As I know, the VMD library had ever been in Boost sandbox for a long time. I had seen some evolution there since Edward tried to enhance the Boost PP libaray. We can learn that some features are missing by the community on end. For example, to deduce a empty macro, those who want to use such features have to rewrite their own implementation which could not be well refined. The Edward's library, as well as some others, extends the functionality of macro preprocess, give metaprogramming more capability and constraint characteristic. Although, due to the macro preprocessing system, some of such constraints are less conservative and misuse of some macro lead to preprocessing errors, I still think it is worth the effort. For example, to enforce a macro parameter is enclosed by parentheses, I use the IS_BEGIN_PARENS macro, of which the name is changed to IS_TUPLE later in Edward's library. It isn't 100% safety, but give us some ability to manipulate the input stream just like the template trait to the type system. The point is of course that it doesn't give much since the language itself hasn't changed. Macro metaprogramming is still the only one literal programming methodology in C/C++ language before any reflection facilities be included. The VMD library will be handy to use if it is accepted, particularly in enhancement of the language and the libraries, which will boost the language evolvement. I also think that the VMD is better being merged into the Boost PP library, as a sub library. For a header files only library, I don't think that any potential error in this preprocess library could cause big fault in the user end. To my limited knowledge, I suggest that this library is well refined, and I think it should be accepted. Hope that my experience can give some help to the review procedure. Regards, Zhou Zhenghui 2014-08-24 10:43 GMT+08:00 Agustín K-ballo Bergé <kaballo86@hotmail.com>:
On 23/08/2014 10:51 p.m., Niall Douglas wrote:
So, to give a full and proper answer, yes the WG21 papers say no to macros in interfaces, but the recent trend is not in that direction at all [1].
To sum things up: a bit of scoping for macros, less macros as flags, but hardly the obsolescence of macro metaprogramming on which modules have no incidence at all.
If anything, I'd say that the improvements presented by any of the several different modules proposals in flux would be gladly welcomed by libraries like PP and VMD.
Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost