Re: [Cppunit-devel] equality of const objects

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

On Tue, Sep 25, 2001 at 05:13:33PM +0200, Baptiste Lepilleur wrote:
> Quoting "Steve M. Robbins" <ste...@vi...>:
> 
> > On Tue, Sep 25, 2001 at 02:56:55PM +0200, Baptiste Lepilleur wrote:
> > 
> > >   I'm not saying to change CppUnit as a whole. The only thing I want
> > >   to change is those part of CppUnit that would impose on the
> > >   "user" policy:
> > > 
> > >  struct assertion_traits 
> > >   {  
> > >       static bool equal( const T& x, const T& y )
> > > => change to 
> > >       static bool equal( T& x, T& y )
> > > 
> > >   and 
> > >     template <class T>
> > >     void assertEquals( const T& expected,
> > >                        const T& actual,
> > > => change to:
> > >     template <class T>
> > >     void assertEquals( T& expected,
> > >                        T& actual,
> > >  
> > >   The change is invisible for user that apply the "const" policy, and
> > allow 
> > > user who don't to use the assertEquals without having to do
> > const_cast.
> > 
> > Sorry Baptiste, I do not understand.  Why do you say that using const
> > references makes writing equal() black magic?  Can you give us a short
> > example of a class that is problematic for equal(const&,const&)?
> 
>    Example of assertion_traits for FileDependency:
> 
>       static bool equal( const FileDependency& x, const FileDependency& y )
>       {
>         return const_cast<FileDependency&>(x).equalsTo( 
> const_cast<FileDependency *>( &y ) );
>       }
> 
>       static std::string toString( const FileDependency& x )
>       {
>         return const_cast<FileDependency&>( x ).toString();
>       }
> 
>       The const_cast are the things I call "black magic".

I agree.  However, in my mind, this raises the question "why don't the
FileDependency methods equalsTo() and toString() have a const
qualifier on them?"

Yes, I understand: you don't want to impose policy on the user.
Fair enough.


>     template <class T>
>     void assertEquals( const T& expected,
>                        const T& actual, ... )
> 
> => change to :
>     template <class T>
>     void assertEquals( T expected,
>                        T actual, ... )
> 
>     This means that pass-by-value would be use instead of const reference. 
> Means that tested object should either have a copy constructor or be pointer.

It also implies a lot of useless copying if you're comparing lists,
n'est pas?  

Can't we have both?  What about 

     template <class T>
     void assertEquals( const T& expected,
                        const T& actual, ... )
 
     template <class T>
     void assertEquals( T& expected,
                        T& actual, ... )
 
with the same implementation.
[Ditto for the default assertion_traits template]

I just tried this modification; the library builds and runs
the test suite successfully.  Comments?

-Steve

-- 
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