Boost logo

Boost :

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>
> 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:
> Thanks,
> --Lorenzo
Thanks for the explanation :-)

Boost list run by bdawes at, gregod at, cpdaniel at, john at