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