RE: data access structures, strings

["Jeff Hill" <johill@lanl.gov>]

> I can define a propertyCatalog/Container PC for doubles,
> with a constructor that takes double,
> a cast operator to double,
> and now I can write catA == 3.14,

When designing class PC one does need to be careful about overly gratuitous
constructors, assignment, and conversions operators. 

> g++ 3.3 actually gives an error message:
> error: ambiguous overload for `PC& == double' operator
> error: candidates are: operator==(double, double) <built-in>
> error:                 bool PC::operator==(const PC&)

The ambiguity here appears to be with type double in the design of class PC
and not with "operator==(const PropertyCatalog &)". The propertyCatalog
"operator =" and "operator ==" are non-ambiguous because they will only
accept a "const PropertyCatalog &" reference, and there are no gratuitous
constructors/operators for class PropertyCatalog.

Nevertheless, in many situations it's preferable not to mix interfaces if
the overall class design does not benefit, and you will be better off
creating an PropertyCatalog accessor object for your "container for doubles"
so that the PropertyCatalog interface isn't part of the broad design for
class PC". You can then make interfaces like the following - which brings us
back to what I think you were asking for in the first place.

bool PC::isEqual ( const PropertyCatalog & pc ) const
{
	ObjectCatalog < PC > oc;
	return pc == oc;
}

The new ObjectCatalog < T > convenience class greatly simplifies the effort
required when creating accessor objects conforming to the PropertyCatalog
interface.

HTH

Jeff

> -----Original Message-----
> From: Kay-Uwe Kasemir [mailto:kasemirk@ornl.gov]
> Sent: Thursday, September 29, 2005 8:54 AM
> To: core-talk@aps.anl.gov
> Subject: Re: data access structures, strings
> 
> 
> On Sep 28, 2005, at 11:03 , Jeff Hill wrote:
> >> 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
> >>
> >
> > I agree that this is the correct definition of equivalence.
> >
> > It's somewhat slower to guarantee this, but perhaps necessary.
> >
> > It may be that a fast, but incorrect == operator may not be very
> > useful.
> 
> Marty's right on the mathematical side.
> On the practical side, when I write
>      catA.equals(catB),
> then I'm fairly certain that property catalog catA is compared to catB
> by invoking catA's equal() method.
> 
> With operators I never know.
> I can define a propertyCatalog/Container PC for doubles,
> with a constructor that takes double,
> a cast operator to double,
> and now I can write
>      catA == 3.14,
> but don't know if the catA gets automatically cast to double
> and compared as a number, or if the compiler generates a
> temporary DoubleContainer instance from 3.14 and invokes its
> comparison routine.
> g++ 3.3 actually gives an error message:
> error: ambiguous overload for `PC& == double' operator
> error: candidates are: operator==(double, double) <built-in>
> error:                 bool PC::operator==(const PC&)
> 
> In this case, I understand the message because I just created the mess
> on purpose. But I had cases where I created those operators
> for 'convenience', and a month later I worked on the code, got
> a similar error message, and was very surprised what the compiler had
> done to me to 'help' and now got confused.
> Of course this probably only happens to me, because everybody else
> understands C++ much better and should by all means use the operators,
> but maybe we can still keep the methods in the API in case I have to
> use it.
> 
> Thanks,
> -Kay