Re: [boost] [Review:Contract]

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

On 2012-09-02 21:51, Lorenzo Caminiti wrote:
> On Sun, Sep 2, 2012 at 12:13 PM, Roland Bock <rbock_at_[hidden]> wrote:
>> 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
> No, precondition, postcondition, requires, intialize, extends, etc are
> not macros, only CONTRACT_OLDOF is a macro. The others are
> indentifiers that have special meaning when used in specified places
> within the library macros. That's all. In a way these are similar to
> C++11 virtual specifiers (which are also not keywords) but for the
> library instead of the language. For example, you could do:
>
> #include <contract.hpp>
>
> CONTRACT_FUNCTION(
>     void (precondition) ( int x )
>         precondition( x >= 0 )
> ) {
> }
>
> int main ( void )
> {
>     precondition(0);
>     return 0;
> }
>
> I advice not to use precondition, etc outside the uses that the lib
> does. However, if you have existing code with a function, variable,
> etc named precondition, my lib will leave that alone (as it should).
> That won't be the case instead if we did #define oldof ... in which
> case if you have existing code that uses oldof it will be messed up.
>
> That said, I can't use the same pp parsing mechanism I use for
> precondition, etc also for oldof because oldof is nested within the
> assignment expression (while precondition, etc appear at the beginning
> of their syntactic element). precondition is the first token so it can
> be parsed as a specifier:
>
> precondition( ... ) // ok
>
> odlof is not the first (or last) token (and all other tokens around
> are arbitrary plus they can contain non-alphanumeric symbols) so it
> can't be parsed by the pp:
>
> auto old_size = oldof size() // nope :(
>
> but I can use a macro to get around this:
>
> auto old_size = CONTRACT_OLDOF size() // ok
>
>> If that is not possible (as with oldof), I could still write:
>>
>> CONTRACT_CONFIG_DEFINE_OLDOF_KEYWORD // defines oldof
> Thanks,
> --Lorenzo
>
>
Thanks for the explanation :-)