Re: data access structures, strings

[Marty Kraimer <mrk@aps.anl.gov>]

Jeff Hill wrote:

> Please pardon an internal debate converted to a mail message :-)
>
>  
>
> > > Use 'assign' instead of 'operator =',
> > > 'isEqual' instead of 'operator ==',
> > >      
> > Shouldn't this also apply to dataAccess? {Or should I say :-) }
> >    
>
> PropertyCatalog currently has "operator =" and "operator ==". 
>
> O Do they meet the conventional wisdom test? That is, is their purpose
> roughly equivalent to the purpose of these operators with primitive types? I
> Originally I thought yes, but I have thought about this further and its
> probably more accurate to call 'operator =' "extract what's in the LHS from
> the RHS", and what 'operator ==' does "return true if everything in the LHS
> is equivalent in the RHS". 
Should  == (or equals) always guarantee that it is an equivalence relation?

That is

1) reflexive =>  x==x is always true
2) symetric  => if x==y then y==x
3) transitive => if x==y and y==z then x==z

Java states that if a class overrides equals it should gurantee that its 
implementation is an equivalence relation.

I suspect similar advice appears somewhere for C++.

dataAccess == does not appear to be  symetric

If containers are implemented for

struct A { int x; int y} and struct B {int x; int y; int z}

Then won't the following happen if A.x=B.x and A.y=B.y?

A==B is true but B==A is false

Marty