Newsgroups: comp.lang.c++
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!unixg.ubc.ca!atherton
From: atherton@unixg.ubc.ca (Bruce Atherton)
Subject: Overloading . for virtual memory
Message-ID: <1991Apr12.173403.8552@unixg.ubc.ca>
Sender: news@unixg.ubc.ca (Usenet News Maintenance)
Nntp-Posting-Host: chilko.ucs.ubc.ca
Organization: University of British Columbia, Vancouver, B.C., Canada
Date: Fri, 12 Apr 1991 17:34:03 GMT

I have only one reason to want both the . and the -> overloaded: To allow
for virtual memory so I can get around the revolting 640K limitations
imposed by MSDOS.

If I write a bunch of classes for distribution, I don't want to insist
that anyone who uses my classes has to use pointers.  I don't want to
force them to have to use "(&struct)->member" either.  Another
option would be to have every function that uses or calls the member
do its check to make sure it is in memory.  Yecch!

I know you can't design a language around the problems of one operating
system, but don't you think if it is useful in this context, it could
be useful elsewhere?

I haven't paid much attention to this whole discussion concerning
the . operator (or whatever you want to call it) because people are
becoming so emotional about it, IMHO.  I know that I don't absolutely
have to have both . and -> overloadable.  It sure would make my life a lot
easier and my classes more useable, though. 

If . doesn't become overloadable, things will be more difficult for me
but I'll live.  What will happen to you if it does become overloadable?
Anything negative at all?  I doubt it.
--
UBC Faculty of Law Artificial Intelligence Research (FLAIR) Project
atherton@unixg.ubc.ca     or | I can almost taste your dandruff as I reach
Bruce_Atherton@mindlink.UUCP | out for your face, and I STRIKE! - The DKs