Re: [boost] [Review:Contract] Andrzej's review

Subject: Re: [boost] [Review:Contract] Andrzej's review
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2012-09-06 12:50:31

On Sat, Sep 1, 2012 at 2:26 PM, Lorenzo Caminiti <lorcaminiti_at_[hidden]> wrote:
> On Fri, Aug 31, 2012 at 2:41 AM, Andrzej Krzemienski <akrzemi1_at_[hidden]> wrote:
>> 2012/8/30 Lorenzo Caminiti <lorcaminiti_at_[hidden]>
>>
>>> On Wed, Aug 29, 2012 at 2:48 PM, Andrzej Krzemienski <akrzemi1_at_[hidden]>
>>> > you cannot use some C++ constructs that you
>>> > would otherwise use;
>>>
>>> Like, for example? (Because I made a conscious effort to support "all"
>>> C++ declaration features in the DSEL, if at all possible...) I know of
>>> function pointers, arrays, member initializers in deferred
>>> implementations but there are workaround for those. Anything else?
>>>
>>
>> Indeed, the support for C++03 declaration is satisfactory. When i wrote it
>> I mostly meant the limitation where "when member initializers are
>> specified, the constructor body must be defined together with its
>> declaration and contract". Apart from this and array or function types I
>> did not think of anything else. But now, that I think of it, I wonder how
>> vendor-speciffic extensions are (or could be) supported, like Microsoft's
>> __declspec? While they are not C++-standard I must use them when
>> implementing a DLL.
>
> No non-standard declaration feature are currently supported. I'll
> consider supporting some in the future:
> https://sourceforge.net/apps/trac/contractpp/ticket/69
>
> Especially if they are simple pass through for the lib (i.e., the pp
> parses them and the implementation of the macro just expands the C++
> declaration code), it's trivial to implement this stuff.

I was thinking more on how to support compiler-specific declaration
extensions. Supposedly, the lib will not do anything with these but to
repeat them verbatim when the macros expand the underlining C++ code
(because these extensions do not affect Contract Programming).
Therefore, I was thinking that I could support a generic verbatim(...)
identifier that can appear anywhere within the declarations and will
specify tokens that the lib will simply repeat "as is" in the actual
C++ declarations of the expanded macros. For example:

CONTRACT_CLASS(
    verbatim(__declspec(dllimport)) class (x)
) {
    CONTRACT_CLASS_INVARIANT( void )
} varx;

CONTRACT_CLASS(
    class verbatim(__declspec(dllimport)) (x)
) {
    CONTRACT_CLASS_INVARIANT( void )
};

If possible, this could be used to support a number of different
(all?) compiler extensions because the lib doesn't need to know
anything about the content of a verbatim clasule but just that the
specified tokens have to be repeated "in place and as they are" when
expanding the macros.

In contrast if I implement the code below, it will only work for
__declspec and not for other extensions (because the lib needs to be
aware of __declspec and not just of verbatim here):

CONTRACT_CLASS(
    __declspec(dllimport) class (x)
) {
    CONTRACT_CLASS_INVARIANT( void )
} varx;

CONTRACT_CLASS(
    class __declspec(dllimport) (x)
) {
    CONTRACT_CLASS_INVARIANT( void )
};

What do you think?

Thanks,
--Lorenzo