On Thu, Jan 23, 2014 at 11:53 AM, Thorsten Ottosen < thorsten.ottosen@dezide.com> wrote:
On 22-01-2014 14:05, Dominique Devienne wrote:
On Wed, Jan 22, 2014 at 1:21 PM, Thorsten Ottosen < thorsten.ottosen@dezide.com> 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 Catch::ExpressionDecomposer::op-> 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