RE: data access structures, strings

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

Oops. I neglected to pass the this reference to the accessor constructor. 


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

> -----Original Message-----
> From: Jeff Hill [mailto:johill@lanl.gov]
> Sent: Thursday, September 29, 2005 9:40 AM
> To: 'Kay-Uwe Kasemir'; core-talk@aps.anl.gov
> Subject: RE: data access structures, strings
> 
> 
> > 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