[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Assignment between strong pointers
- To: <xtech@son-of-blob>
- Subject: Assignment between strong pointers
- From: <eric@son-of-blob>
- Date: Tue, 7 Nov 89 11:37:26 PST
My earlier test of assignment of strong pointers to typeA to strong pointers
to typeBaseClassOfA apparently didn't cover enough cases. Check this out.
We may want to pass this to Nat, or maybe even Bjarne. Some X++isms have been
removed for that reason.
Consider the canonical example class hierarchy
class Foo
class Bar : public Foo
Let these be declared and let PTR(Foo) and PTR(Bar) be declared as
#define PTR(TYPE) CAT(StrongPtrTo_,TYPE)
class PTR(TYPE) : public StrongPtrVar {
public:
LEAF void printOn (ostream& oo);
LEAF TYPE* operator-> ();
LEAF TYPE& operator* ();
LEAF PTR(TYPE)& operator= (const PTR(TYPE)& other);
LEAF PTR(TYPE)& operator= (TYPE * other);
LEAF BooleanVar operator== (const PTR(TYPE)& other);
LEAF BooleanVar operator!= (const PTR(TYPE)& other);
LEAF operator TYPE * ();
PTR(TYPE) ();
PTR(TYPE) (TYPE * argPtr);
PTR(TYPE) (PTR(TYPE)& argPtr);
private:
TYPE * value;
};
I have three functions that should be identical as I understand the language:
1) PTR(Foo) func (PTR(Bar) barP) {
return barP;
}
2) PTR(Foo) func (PTR(Bar) barP) {
PTR(Foo) fooP = barP;
return fooP;
}
3) PTR(Foo) func (PTR(Bar) barP) {
PTR(Foo) fooP;
fooP = barP;
return fooP;
}
The compiler, however, doesn't see these as I do. Cases (1) and (2) both
cause the error "cannot make a StrongPtrTo_Foo from a StrongPtrTo_Bar,"
while case (3) compiles happily. This looks very much like the same problem
that causes the "not implemented: pointer expression too complicated for delete"
message when anything more than a trivial pointer expression appears next to
a delete. The case above, however, makes no "not implemented" apology. Does
anybody have any clever ideas? This is not fatal, since troublesome places in
the X++ code can be written as in case (3) with no semantic change. It is
annoying though.
- e -