Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!rutgers!ub!oswego!news
From: dl@g.g.oswego.edu (Doug Lea)
Newsgroups: comp.std.c++
Subject: Re: the most dissatisfying part of c++
Message-ID: <DL.90Aug4080614@g.g.oswego.edu>
Date: 4 Aug 90 12:02:05 GMT
References: <56236@microsoft.UUCP> <1816@cs.rit.edu>
Sender: news@oswego.Oswego.EDU (Network News)
Reply-To: dl@g.oswego.edu
Organization: SUNY Oswego
Lines: 70
In-reply-to: jeh@cs.rit.edu's message of 3 Aug 90 18:51:39 GMT


From: jeh@cs.rit.edu (Jim Heliotis)

> > The change to the existing rules is to allow overidings of virtual
> > functions to return a type to which a standard conversion may be
> > applied to obtain the inherited return type.  ("standard conversion"
> > may be too general; perhaps only derived-to-base standard conversions
> > should be applicable).  The appropriate member function signature would 
> > be chosen according to the static type of the pointer through which
> > it is invoked.
> > 
> 
> OK, I'll put my two cents in:
> 
> - Look at Eiffel.  They do this with some sort of type attribute called
>   something like "SAME AS", so you could declare you are returning an
>   object the same type as one of your arguments.
>   This works because I believe Eiffel's implementation includes class ids
>   in objects, but I could be wrong.

But look at W. Cook's ECOOP '89 paper to see how `LIKE CURRENT' (`SAME AS')
can create holes in a type system. Making something like `typeof' a first
class primitive is equally problematic because an object of
a derived class may be said to have many types, from leaf to root of an
inheritance tree. 

> - It appears to be hard to solve this problem without dynamic class ids.
> 
> - Most C++ classes relevant to this need /have\ dynamic class ids -- their
>   virtual function table addresses!  Now, this does not help much when dealing
>   with persistent objects, but is it worth a shot?

Not entirely relevant: In C++ you can either get static (compile-time)
resolution or dynamic (run-time) resolution. With non-virtual
functions/classes, you are always limited to static resolution, for
better and worse, but the same rules apply to the extent to which
types are known at compile time. So programmers don't absolutely need
dynamic ids as long as they know that static resolution does the right
thing in a particular application.

While I'm at it, here's a different angle towards explaining the 
basic idea. Suppose the original example were redone so that
a::test() returned a pointer, and pointers were used in main().

#include <stream.h>
class a { 
  public: 
    a* test() {  // *** original said `a& test()'
	// do some modification to the state of this object,
	// then ...
	return this; // *** original said `return *this;'
};
class b : public a { 
  public:
    int b;
};
main() { 
  a* B = new b;  // *** original said `b B;'
  B = B->test(); // *** original said `B = B.test();'
}

This has no type violations. The `customization' proposal extends this
usage to apply to references and values by adding a type qualifier
requesting such behavior, along with rules to support it.

-Doug
--
Doug Lea, Computer Science Dept., SUNY Oswego, Oswego, NY, 13126 (315)341-2688
email: dl@g.oswego.edu            or dl@cat.syr.edu
UUCP :...cornell!devvax!oswego!dl or ...rutgers!sunybcs!oswego!dl