Re: [Cppunit-devel] equality of const objects

[Steve M. R. <ste...@vi...>]

On Mon, Oct 01, 2001 at 12:45:40PM -0700, Duane Murphy wrote:

> I would also make the argument (FWIW) that const is all that is needed.
> Comparison operators should not be mutating. (Caches are caches and
> should be marked mutable.)

I happen to agree with you.  If it were my decision alone, I'd just
leave things as-is and let the folks who can't compare const objects
to suffer for their sins.  ;-)


> This is also where you want to make the change for comparing equivalent
> objects (not the same type). The change would be thus:
> 
>      template <class TExepect, TActual>
>      void assertEquals( const TExepect & expected,
>                         const TActual & actual, ... )

I'm fairly skeptical that we want to allow this.  

I seem to recall changing my local copy of CppUnit some months ago to
allow assertEquals() on two different types.  And I seem to recall
running into problems because the compiler likes to promote types
and use implicit conversions and all the other good stuff.  
Sorry to not be more specific at this point...

The question, in my mind, is: why are you comparing two different
types for equality, anyway???

There are two alternatives that come to mind:

1. Construct an appropriate "expected" value to begin with.
   If you claim the two types are "equivalent", then you should
   be able to construct an appropriate object.  In the enum/int
   example, use CPPUNIT_ASSERT_EQUAL( int(noErr), FunctionToTest() );


2. Make up your own comparison functions and use CPPUNIT_ASSERT.

	bool my_equality_T1_T2( const T1& x, const T2& y ) { ... }

	#define CPPUNIT_ASSERT_EQUALS_T1_T2(x,y) \
		CPPUNIT_ASSERT( my_equality_T1_T2(x,y) )

   I do this sort of thing all the time.  Not everything needs to be 
   in the base library.


-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants