home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.c++
- Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
- From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
- Subject: Re: Covariant Types in Derived Classes
- Message-ID: <1992Jul24.184431.12761@ucc.su.OZ.AU>
- Sender: news@ucc.su.OZ.AU
- Nntp-Posting-Host: extro.ucc.su.oz.au
- Organization: MAXTAL P/L C/- University Computing Centre, Sydney
- References: <P6C5COF@netmbx.netmbx.de> <1992Jul23.205820.24559@ucc.su.OZ.AU> <VKE52M@netmbx.netmbx.de>
- Date: Fri, 24 Jul 1992 18:44:31 GMT
- Lines: 142
-
- In article <VKE52M@netmbx.netmbx.de> jrobie@netmbx.netmbx.de (Jonathan Robie) writes:
- >maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
- >
- >So far we have seen that RTTI is very useful for debuggers, class browsers,
- >report generators, user interface tools, databases, communications...
- >in other words, for a great deal of the programming tools a C++ programmer
- >would like to have.
-
- Yes. All these require a fixed piece of code to be able to
- manipulate arbitary objects, right?
-
- If you want to add RTTI to facilitate this, I have no
- argument. I might argue, however, that such systems---
- tools for manipulating C++ itself, introspective you called them,
- I called them 'meta' systems, and also for interfacing to
- foreign interfaces--- are a different class than garden
- variety programs---domestic systems. I would like to
- see domestic systems protected from such power.
-
- Lets suppose you allow domestic programs access to all type info.
- Then there's not much point hiding the implementation is there?
-
- However, I think what is proposed is MUCH more limited than this.
- So it won't give you what you want, but it will encourage
- and allow bad style in domestic programs.
-
- Note that what YOU want for the introspective
- systems doesn't involve downcasting, it involves
- MUCH deeper penetration into the system, all such systems
- have to get at details that ought to be hidden in
- domestic systems.
- >
- >> 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 providing a default which may be used directly or edited with
- >a mouse is not a pain, and is easily provided as a general tool.
-
- OK.
- >
- >Let me give you an example from POET, the OODB that I know
- >best (because I am one of the developers). Let's say you have
- >an arbitrary class declaration:
- >
- > class ArbitraryClass {
- > int foo;
- > public:
- > float goo;
- > };
- >
- >If you just write the little word "persistent" in front of this then
- >our precompiler will know that it should generate run time type info:
- >
- >
- > persistent class ArbitraryClass {
- > int foo;
- > public:
- > float goo;
- > };
- >
- >If an object is assigned to a database then you can store it using
- >the Store() method, which is provided for all persistent objects:
- >
- > ArbitraryClass ArbitraryObject;
- >
- > ArbitraryObject->Assign(ADatabase);
- > ArbitraryObject->Store();
- >
- >I'll avoid going into more detail right now, but you see that this
- >is very convenient. Without RTTI it is not possible. We do not need
- >a reflective system, but we do need an introspective system. Since
- >C++ is not introspective, we have built our own compiler to give us the
- >information which all C++ compilers generate and then throw away.
-
- So for this RTTI is needed. It HAS to know the
- implementation details! It CAN break the system, so you
- had better buy a good OODB like POET :-) that you trust.
- >
- >I am concerned that many C++ programs downcast without any guarantee
- >of type safety. Start reading large C++ programs and you will see that
- >downcasts are quite common. Is the C++ community worse off if we provide
- >a safer way to do this?
-
- In domestic programs it would best to bad downcasts :-)
- They not necessary. And the're not possible for virtual bases,
- so I make all my bases virtual to make absolutely sure you
- cant break the type system. I dont want you to be able to do
- it safely---I dont want you to be able to do it at all!
-
- For the same reason I dont want to to access the private variables.
- Saying 'but you need to do that for a debugger, an OODB etc'
- is saying something true: but that doesnt mean I want you to be
- able to do it domestically. The same argument could be used
- to say 'lets get rid of private and make everything public'
-
- I dont want this domestically,
- and downcasting is precisely the same issue.
-
- >
- >> 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.
- >
- >Naw. The problems *I* am discussing have already been solved
- >using C++, but we are finding sneaky ways to get at run time type
- >information.
-
- Exactly. You want a dynamic system. C++ is static
- and somewhat typesafe because of that. You want to do something
- that cant be done safely in the first place. So C++
- is the wrong tool, it is restricted to PREVENT the sort of program
- you want to write being written.
-
- i agree to extend its scope, provided that this can be
- done without prejudicing the safety of domestic systems,
- which are the pricipal goal (all those debuggers are not
- going to be used *just* to debug themselves!)
-
- So I'm NOT against RTTI, or what you want to do with it,
- I'm sure thats why Bjarne is supporting it. I want to
- do those sorts of things TOO.
-
- >
- >> Wouldn't you rather just say 'persistent' and have the object
- >>just exist in the 'persistent' database totally automatically :-)
- >
- > Because the user shyould have some control over which objects
- > get stored, and should be able to test the store operation for
- > error returns. But you have the right idea! And if you look
- > at my sample code given above--from a commercial system that
- > is now available--you see that this kind of high level access
- > is possible in C++ today, given RTTI.
-
- Sure. We agree here. Just not about the need or advisability
- of downcasting in domestic, statically determined programs.
-
- --
- ;----------------------------------------------------------------------
- JOHN (MAX) SKALLER, maxtal@extro.ucc.su.oz.au
- Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
- ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
-