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

On 8/25/2014 6:04 PM, Rodrigo Madera wrote:

On Mon, Aug 25, 2014 at 3:12 PM, Edward Diener wrote:

...

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.

Could you please provide a link to this mentioned safety philosophy of Boost PP?

There is no link I can give, other than to say it is my interpretation of the philosophy of Boost PP from looking at code and working/talking privately with Paul. I do not believe that passing incorrrect data to Boost PP functionality will ever produce a preprocessing error. It may produce an undefined result but that is then the programmer's problem misusing some functionality of Boost PP. Another example of the "safety philosophy" of Boost PP is that Paul was well aware that he had written a better variadic macro to test for emptiness, as well as that the Boost PP library has an undocumented non-variadic test for emptiness used internally. He did not want the current non-variadic version to be documented and he made no move to add the variadic version to Boost PP. In general he has always been very careful to not introduce any functionality in Boost PP that could produce incorrect results when used "correctly", as well as being very careful not to introduce functionality into Boost PP which could cause programmers to misuse the library by making anything more complicated than he felt it need be. This is what I mean by his "philosophy of safety".

As far as I can tell, Boost PP will give strange results if you don't obey its design constraints. I.e., try to use a malformed tuple.

But it does not create a preprocesing error AFAIK. It basically is telling you that passing the wrong sort of data gives you undefined results and that the undefined results are not any of the expected results.

Is Boost PP using some kind of protection that VMD isn't?

No, VMD is simply designed in a number of cases without any protection if you feed it something it cannot handle, simply because there is no way you can use the preprocessor to pre-detect the sort of thing which could give a preprocessor error. This is not always the case and VMD does the best job it can to detect invalid input and act accordingly. But VMD accepts, because of the extended functionality it offers, that some incorrect input can give a preprocessing error. This is part of what I talk about in the documentation when I mention input "constraints". The defacto example of this in VMD is parsing/identifying a number or identifier. In order to do this it uses preprocessor concatenation ( the '##' symbol ). For this to work in VMD the preprocessor token being tested must not begin with anything which is not an alphanumeric, underscore, or the left parenthesis of a tuple ( all of which in the VMD docs resolves to what is called "vtype" preprocessing data ). VMD cannot catch an error if you attempt to identify as a number or an identifier a preprocessor sequence of tokens starting with "&aname" let us say. It is just impossible to do. But the functionality is still there because VMD takes the philosophy that the macro creator using VMD has set as a constraint for the user of a macro that the input being tested is what VMD can handle correctly for a particular use of its functionality. If the end-user does not follow the "constraint" of a macro designer for some type of input, and therefore a compiler preprocessor error is unavoidably produced, it is the end-user's fault in the opinion of VMD. So if you have some input like "&aname" you can certainly use it as is in your macro programming but you can't pass it to anything in VMD expecting it is one of the v-types which VMD understands. That's what I mean by VMD being different than Boost PP. VMD pushes the bounds of what you can do in the preprocessor, using variadic macro techniques, with the knowledge that incorrect input to its functionality will sometimes just stop the preprocessor with an error. Boost PP never does this AFAIK, in the interests of safety. Both have their place but to me they are two different libraries.