Re: [boost] [Review:Contract]

Subject: Re: [boost] [Review:Contract]
From: Roland Bock (rbock_at_[hidden])
Date: 2012-09-02 15:13:16

On 2012-09-02 19:49, Lorenzo Caminiti wrote:
> * What is your evaluation of the implementation?
> I spent some time browsing through the macro code hoping it would help me to solve a problem of my own which looked similar (turned out it wasn't).
> What's the problem you are trying to solve? (Maybe post it in a
> separate email thread.)
Will do, topic will be "Enum Conversion".
>
>> Never being a fan of too much macro code, I have to say that this is very nicely written!
>>
>> My only concerns:
>> - It seems to me that the implementation is spread over
>>   more files than necessary. It made following the call stack
>>   a bit tiresome.
> I refactored the files many times... what's there now makes sense to
> me, modularity is important given the amount of pp code this lib has.
> Do you have any specific suggestion on some files that should be
> merged together?
No specific suggestions, I just tried to follow the "requires" through
the code and found myself hopping from file to file for every other
function. At least it felt that way.
>> - I a bit torn between
>>   a) Steven's comment who would like to see CONTRACT_OLDOF
>>      being replaced by the would-be keyword in a possible
>>      future standard
>>   b) boost macros being clearly visible as such, leaving
>>      translation to future standard keywords to the user
>>      of the library, e.g.
>>      #define foreach BOOST_FOREACH
>>
>>   I tend towards b).
> I just replied to Steven's. CONTRACT_OLDOF is a "special" macro so
> #define oldof CONTRACT_OLDOF won't work (because you can't guarantee
> proper expansion order that way) but I can provide a
> CONTRACT_CONFIG_DEFINE_OLDOF_KEYWORD that will #define oldof for you
> (even if oldof doesn't follow the Boost macro naming standard).
Hmm. I wonder if precondition, postcondition, requires etc. might have
the potential to confuse users who are not aware of Boost.Contract? They
look like language keywords, but are macros instead. That's why I said I
am tending towards b) which would at least define the keyword locally, e.g.

#define precondition BOOST_CONTRACT_PRECONDITION

If that is not possible (as with oldof), I could still write:

CONTRACT_CONFIG_DEFINE_OLDOF_KEYWORD // defines oldof

Regards,

Roland