NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/lang/cplus/11453

Text File | 1992-07-23 | 5.6 KB | 142 lines

Newsgroups: comp.lang.c++
Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
From: [e-mail] (John MAX Skaller)
Subject: Re: Covariant Types in Derived Classes
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: extro.ucc.su.oz.au
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 23 Jul 1992 20:58:20 GMT
Lines: 129

In article <[e-mail]> [e-mail] (Jonathan Robie) writes:
>[e-mail] (John MAX Skaller) writes:
>
>>In article <[e-mail]> [e-mail] (Jonathan Robie) writes:
>>>[e-mail] (John MAX Skaller) writes:
>
>>>Then you
>>>need to find out how many members you have in each class and how to
>>>access them.....
>
>>    I dont understand.
>
>If I want a generic print function that can handle all types as though they
>were basic types, then this print function must know the location and type
>of each member, and also the name if the function is to be particularly
>useful.

    Such a utility function would be useful for debugging only.
Yes, to do it you would need RTTI.

    To make proper output *requires* programmer definition,
when I need this I just have a virtual print in all relevant classes.
Of course, then I have to *write* the definitions, which is a pain.
>
>>but NOT to streams. I use Windows, there are NO streams
>>(well, there are: disk files I personally open).
>>    So you see immediately there is a problem here.
>
>But if Windows provides you with general tools like the ones
>I am describing then there is no such problem.  To do so they
>need the run time type information.

    It would be the compiler's library that would have to
support conversion from RTTI to say an object browser Window.
Yes, this would need RTTI.
>
>>What concerns me is that, for example, if you can say
>>get a description of the details of a class,
>>then you can 'cheat' the system, and fiddle with details
>>that were supposed to be hidden.
>
>You can do this with pointers also.

    Yes, every 'cast' is a cheat.

>What concerns me is that
>people are already writing precompilers for C++ simply because
>they need this run time identification for such bread and butter
>applications as object oriented databases.  That is OK if only
>one of the tools you use needs a precompiler, but when you need
>two tools which each need a precompiler this can lead to problems.

    OK, so you want a standard way of doing it. I cant
disagree that where you need RTTI for foreign interfacing
it would be better provided as standard.

>
>Similarly, if every tool you use defines an Object type from which
>all of your classes must be derived then you start having problems
>when you want to use several tools simultaneously.

    Why would you do something so stupid as derive everything
from Object? That is a totally out of date idea IMHO. Thats
what MI is for: so you don't have to do this sort of Smalltalk
emulation: it may be OK in Smalltalk, but it is totally wrong
to make heirarchies in C++ when you should have DAGs.

[Above is pitched a bit extremely, no flame intended. And
here's my definition of object:

    class object { public: virtual ~object(){} };

]
>
>>Of course, in an OO database you might want to do exactly that:
>>how else can the user define a new object?
>
>>But then you are writting in C++ a new system, and an interpreter
>>aided by the C++ run-time system: I don't know what you
>>call this class of programs, but for this class of programs
>>you need run-time support---LOTS of it. No argument.
>
>No, I am not aware of any OO database which uses an interpreter
>to build class methods.  Typically, a standard C++ constructor
>is used to create a new object.  But the database maintains a
>class dictionary to keep track of data members.

    Oh, you mean that the database does NOT actually define new
objects, the user has to write a program to create them?
(To supply the constructor, which must be compiled C++ code)
Then the OODB just stores the stuff, and has to retrieve
it and convert it back to an object, which is a bit
of a problem even WITH RTTI (because the object doesn't yet
exist, so the RTTI is useless).

>Object oriented databases are a very typical tool for use with
>C++, as are user interface tools, CASE tools, communications
>packages, etc.   The C++ community is better off if these tools
>are easily available.  You do not need a fully reflective system
>to provide these tools, and you would not need precompilers if
>the run time identification were available.

    Fair enough.
>
>>Why not use Smalltalk or Lisp: they already have the
>>properties you need. C++ with only run-time support
>>added will STILL be almost unworkable for a system
>>like an OO database that really requires reflexivity.
>
>Type safe systems are essential.  Neither Smalltalk nor Lisp are
>type safe.

    Yes. 'tis why I am concerned that RTTI will be used
to do downcasting, which, although not invalidating type safety,
invalidates the open/closed principle.

    The problems you want to solve (me too, and many others :-)
are way out of te scope of a traditional language which
works only with memory resources. THAT is the problem, really.

    Wouldn't you rather just say 'persistent' and have the object
just exist in the 'persistent'  database totally automatically :-)


--
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         [e-mail]
    Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------