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 20:39:40
On 8/25/2014 6:04 PM, Rodrigo Madera wrote:
> On Mon, Aug 25, 2014 at 3:12 PM, Edward Diener <eldiener_at_[hidden]>
> 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.