Boost logo

Boost :

Subject: Re: [boost] [Boost.Test] Assertion changes in trunk? [WAS: Call for Review: Boost.Test documentation rewrite]
From: Dominique Devienne (ddevienne_at_[hidden])
Date: 2014-01-23 07:32:09

On Thu, Jan 23, 2014 at 11:53 AM, Thorsten Ottosen <
thorsten.ottosen_at_[hidden]> wrote:

> On 22-01-2014 14:05, Dominique Devienne wrote:
>> On Wed, Jan 22, 2014 at 1:21 PM, Thorsten Ottosen <
>> thorsten.ottosen_at_[hidden]> wrote:
> Completely reliable. You just bind the first object to some wrapper
>>> class object which provide the overloaded operators (via delegation).
>> This seems to rely on an op->* operator, which has lower precedence than
>> unary op* (dereference), and the macro INTERNAL_CATCH_TEST uses
>> un-parenthesized Catch::ExpressionDecomposer()->*expr, so won't this
>> break
>> if I do MACRO(*lhs_ptr == *rhs_ptr)?
> Hm. I haven't tried that. Isn't it sufficient that ->* has higher
> precedence than the comparison operators?

The precedence I was concerned about was not op== Thorsten, but unary op*.

Apologies, my example is probably not what I meant. Here's another try:

MACRO(lhs_ptr == rhs_ptr) expands to

OTHER_MACRO(Catch::ExpressionDecomposer()->*lhs_ptr == rhs_ptr, ...)

And since unary op* has higher precedence than op->*, I think that's
equivalent to

OTHER_MACRO(Catch::ExpressionDecomposer()->(*lhs_ptr) == rhs_ptr, ...)

I.e. no longer Catch::ExpressionDecomposer::op->* and lhs, but
and (*lhs). Thus compile error? Not tried, obviously...

Perhaps it doesn't matter if the only goal of ExpressionDecomposer is to
know what operator is used by the expression, and it doesn't care about the
type the template param of its op->* becomes, but in this case it looks to
me that the 'star' will associate to lhs, not to ->. Again, I'm no C++
expert. I'm just concerned over such trickery "just" to have a single
macro, in Catch and more importantly here to Boost.Test. --DD

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