On Sat, Sep 1, 2012 at 2:26 PM, Lorenzo Caminiti <lorcaminiti@gmail.com> wrote:
On Fri, Aug 31, 2012 at 2:41 AM, Andrzej Krzemienski <akrzemi1@gmail.com> wrote:
2012/8/30 Lorenzo Caminiti <lorcaminiti@gmail.com>
On Wed, Aug 29, 2012 at 2:48 PM, Andrzej Krzemienski <akrzemi1@gmail.com>
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