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-22 17:00:30

On 8/22/2014 3:25 PM, Rodrigo Madera wrote:
> Hello Edward,
>
> Nice library.

Thanks !

> I couldn't get the docs going but Daniel James' link [1] did
> the trick. I gave it a quick read and I haven't yet tested out your code.
> But I have some thoughts already.
>
> I have used BOOST_PP extensively for C++03 TMP, so I see a familiar pattern
> here.
>
> To begin, I agree with people here that we need some sort of problem to
> your solution. Right now it seems that VMD is better off just being merged
> into BOOST PP enhancements.

The main reason I did not seek to merge VMD into Boost PP is that I view 
Boost PP as Paul Mensonides library and it is certainly his excellence 
that has created nearly all its functionality. The VMD library also has 
a much more liberal ( technically ) philosophy about what it presents. 
But that I mean that it has to accept the fact that non-constrained 
input can produce preprocessing errors, and that the basis for much of 
the functionality/ability of the library is the ability to detect 
"empty" input or "empty" input elements, an ability that has a very 
slight flaw which has no absolute solution.

>
> Could you provide (as in write and develop) an in-depth comparison of VMD
> with BOOST PP?
>
> What can VMD do that BOOST PP can't?

The main extensions of VMD over Boost PP, given the constraints 
mentioned in the library, are explained generally in the introduction. I 
am also aware that I need to make the introduction more encompassing 
along the lines of why a macro programmer will want to use VMD along 
with Boost PP to do macro metaprogramming. It is certainly a criticism 
of which I am fully aware and is justified to an extent I did not 
foresee when I created the documentation.

The extensions in VMD that go beyond Boost PP are:

1) The ability to parse/identify a subset of preprocessor data types. 
These include all four of the data types invented by Paul for Boost PP, 
which are arrays, lists. seqs, and tuples, as well as individual 
identifiers and Boost PP numbers.

2) The ability to identify "empty" data.

3) The ability to parse a sequence of top-level data types, consisting 
of any of the data types which VMD can parse.

4) Some very useful variadic versions of macros are in VMD which have a 
less useless non-variadic version in Boost PP.

The main advantage of parsing/identify preprocessor data types is like 
one of the main advantages Boost MPL gives you in doing template 
metaprogramming: you can change the logic of macro creation based on the 
particular type of preprocessing data and, in the case of identifiers 
and pp-numbers, the particular value of the proprocessing data, in order 
to create C++ output based on macro input. In other words it gives you 
even more flexibility in design a macro interface to create C++ constructs.

This is never to say that the use of very cleverly designed macros 
should replace the use of C++ constructs themselves in doing C++ 
programming. I would be the first to say that if you can do something 
equally as well with C++ constructs, like variadic templates, than you 
can do with variadic macros, use the C++ constructs as is and leave the 
much normally much less capable preprocessor alone. But there are a 
number of cases where using well-designed macros can make the use of a 
library much easier for the end-user programmer.

>
> Also, I use BOOST PP to overcome C++03 limitations. Now with C++11 much of
> these needs has been eliminated. We've got C++14 here and C++17 is in the
> making. With all that, what is VMD here to solve?

It is an extension to the functionality of Boost PP which gives the 
macro programmer the abilities mentioned above. It does not exist to 
solve any particular problem.

>
> A good example of usage would be very nice. Maybe some macro code
> generation that could make it more interesting, if you will. I don't know,
> I'm just trying to make VMD necessary in some context.

I have never thought about any specific problem. Whatever I might posit 
may well give those who don't ever see the need for macros to generate 
C++ to criticize why a macro should ever be needed.

But here is a possible example, although purely theoretical as to its 
use. Suppose you designed a macro where you were creating a C++ class. 
In the macro you might have some input parameter which, if the user 
specified the identifier 'public' the code you were creating from 
further macro input would go in a base class, if the user specified the 
identifier "protected' the code you were creating from further macro 
input would go in a derived class, and if the user specified 'private' 
the code you were creating from further macro input would go in a pimpl 
class connected to the base class by a pimpl sort of identifier. VMD has 
the ability to test for specific identifiers, such as 'public', 
'protected', 'private', and based on the test you could use the Boost PP 
macro 'BOOST_PP_IIF' to create the output you needed.

In general because VMD can identify a subset, although a heavily used 
one in preprocessor metaprogramming, of preprocessor data types and all 
the Boost PP data types, it adds to the ability to create macros based 
on differing types of input.

In a way it is like any input in data processing in general. Programming 
often responds to input logically, not just mathematically. In a 
function some input may mean we want to logically perform data 
manipulation A while some different input may mean we want to perform 
data manipulation B. In template metaprogramming, some type may mean we 
want to pursue type manipulation A while another type may mean we want 
to pursue type manipulation B. In preprocessor metaprogramming some 
preprocessor data type/value may mean we want to generate C++ code A 
while some other preprocessor data type/value meay mean we want to 
generate C++ code B.

Of course we can ignore the flexibility in any of these arrangements, 
whether at the functional level, the template level, or the macro level, 
and just dictate that the input data must always be some specific thing 
and we will just manipulate it as is. But in general programming based 
on logical flexibility is much easier.

VMD intends to give the macro programmer this sort of logical 
flexibility, within the fairly narrow confines of what the macro 
preprocessor can do, as opposed to the much larger confines of the C++ 
language itself.

Perhaps this whole explanation should have gone into the documentation 
as the "argument for the work" as 17th/18th century writers might put it 
<g>.