Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!intercon!news From: amanda@mermaid.intercon.com (Amanda Walker) Newsgroups: comp.sys.mac.programmer Subject: Re: Multiple Inheritance -- Is It A Luxury? Message-ID: <26940AD2.513@intercon.com> Date: 6 Jul 90 03:51:46 GMT References: <15132@reed.UUCP> <268BA8DC.4CD4@intercon.com> <8937@goofy.Apple.COM> <268C032E.5137@intercon.com> <1990Jul2.181147.1672@efi.com> <8967@goofy.Apple.COM> <1990Jul5.223032.14604@efi.com> Sender: usenet@intercon.com (USENET The Magnificent) Reply-To: amanda@mermaid.intercon.com (Amanda Walker) Organization: InterCon Systems Corporation, Herndon, VA Lines: 27 In article <1990Jul5.223032.14604@efi.com>, tim@efi.com (Tim Maroney) writes: > I have yet to run into a programming model using pointers > into nonrelocatable blocks that couldn't be rephrased in terms of > offsets into relocatable blocks. It may require some work on the part > of the compiler developer -- since they didn't do it right the first > time -- but it's hardly a serious implementation difficulty. In the abstract, you're quite right. However, C++ is a little trickier, thanks (?) to it's heritage from C. In particular, object references are generally treated as being "special" kinds of pointers. Technically, I don't see anything in the language that requires that object references and pointers be the same size, but I suspect that it would be extremely difficult to retrofit such a change into an existing C++ compiler such as cfront (which is what Apple's C++ is based on). Now, I'm all for a from-scratch C++ compiler--one that could handle 64-bit object references and spit out object files instead of C code, but I'd rather have a solid port of cfront to play with until such a beast exists. Even what we've already got is a noticeable improvement over vanilla C... -- Amanda Walker InterCon Systems Corporation -- "I can only assume this is not the first-class compartment." --Hitchhiker's Guide to the Galaxy