AMDG On 09/06/2012 09:50 AM, Lorenzo Caminiti wrote:
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.
One difficulty with this is defining exactly what "in place" means. You'll need to specify how locations in your syntax map to locations in the C++ declaration in all the places where the syntax is different. e.g. void (f)(int i, verbatim(extension) default 10) a) void f(int i extension = 1) b) void f(int i = extension 1) c) This is illegal
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?
I think both are good. You should implement important known compiler extensions like __declspec and __attribute__ directly and also provide verbatim to handle unknown or future compiler extensions. In Christ, Steven Watanabe