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.
> I couldn't get the docs going but Daniel James' link  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
> 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++
Perhaps this whole explanation should have gone into the documentation
as the "argument for the work" as 17th/18th century writers might put it
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk