Re: [boost] [review] Formal review period for VMD library begins today, Aug 21, and ends Sat, Aug 30

On 8/25/2014 5:19 AM, Zhenghui Zhou wrote:

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

Thanks for the link. I will take a look at the work you have done and compare it to the implementation in VMD to see if any of your techniques can improve VMD.

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 version in VMD is called BOOST_VMD_IS_EMPTY and is largely taken from Paul Mensonides' posting on the Internet with a few tweaks of my own, mainly for VC++. I believe it is the closest one can come to testing for emptiness, but no test for emptiness can be perfect. I will look at your version also. I am aware of Jens Gustedt version but it has a larger flaw than the one in VMD even if originally he thought it was flawless. I am convinced from Paul's discussions that no version of testing for emptiness can be flawless but I do explain in the VMD doc why the VMD version will work given macro constraints.

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.

I appreciate your saying this. I did put a great deal of effort into the VMD library, a very large part of it getting it to work with the VC++ preprocessor and its many preprocessing bugs.

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.

I have not looked at your implementation of IS_BEGIN_PARENS. The macro in VMD which is the equivalent of testing whether a sequence of tokens begins with a set of parenthesis ( which may have other tokens within it ) is BOOST_VMD_IS_BEGIN_TUPLE. This macro is 100% safe. Again it is largely taken from a Paul Mensonides posting. In the 'develop' branch of Boost PP I have added the equivalent functionality in the form of the macro BOOST_PP_IS_BEGIN_PARENS. I plan to merge the 'develop' branch of Boost PP to the 'master' branch sometime shortly after the review of VMD is over, no matter what is the final outcome of this review.

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.

The problem of merging VMD into Boost PP is twofold. First Boost PP is still Paul Mensonides library and his philosophy of safety, which I totally respect, is part of Boost PP. Secondly, as you have already said and realize, the philosophy of VMD is that preprocessing errors can occur if the functionality in VMD is misused by a programmer. In other words VMD depends on the constraints discussed in the library to work correctly. But within those constraints it does work and adds a great deal of flexibility to macro metaprogramming and the design of macro input.

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.

Thank you very much for your review.

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