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

Subject: Re: [boost] [review] Formal review period for VMD library begins today, Aug 21, and ends Sat, Aug 30
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-08-25 14:12:41

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é <kaballo86_at_[hidden]>:
>
>> 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