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