ttwang@polyslo.CalPoly.EDU (Thomas Wang) (10/27/89)
Currently there is no portable way to tell if a variable is
allocated as automatic, heap, static, or global.
I propose that C++ be extended to support the following new operators:
void* operator static new (void* where, unsigned int size);
void* operator auto new (void* where, unsigned int size);
void* operator extern new (void* where, unsigned int size);
The traditional void* operator new ... is still reserved for heap variables.
These 'new' operators are called before the constructor phase. The 'new'
operators can set a flag inside the structure to tell the storage
type of the variable.
#define HEAP 0 // heap variable
#define AUTO 1 // local variable
#define STATIC 2 // static variable
#define EXTERN 3 // global variable
class foo
{
int storage_type;
public:
void* operator auto new(foo* where, unsigned int size)
{ where->storage_type = AUTO; return where; }
void* operator static new(foo* where, unsigned int size)
{ where->storage_type = STATIC; return where; }
void* operator extern new(foo* where, unsigned int size)
{ where->storage_type = EXTERN; return where; }
void* operator new(unsigned int size);
kill_myself()
{ if (this->storage_type == HEAP) delete this; }
};
void* foo::operator new(unsigned int size)
{
void* ptr = malloc(size);
ptr->storage_type = HEAP;
return ptr;
}
-Thomas Wang (There is a maniac in the bathtub!!
-Akane in "Ranma 1/2")
ttwang@polyslo.calpoly.edushap@delrey.sgi.com (Jonathan Shapiro) (10/28/89)
I want to propose 20 new operators for C++. My problem can only be solved by the introduction of these new operators, because nobody else understands the issues involved, and since, having never designed a programming language, I am an expert, I am sure this proposal will be uniformly agreed upon as the Right Thing. The operators are needed to support NGC (Neato Garbage Collection), a proprietary algorithm that I can't tell you much about except for the fact that it eliminates garbage selectively on the basis of how old it is, which is why I need all these new operators. The necessary support for these operators is supplied by dedicated hardware sold only by my friend's company. void *operator teenaged(void *object_pointer); void *operator mature(void *object_pointer); void *operator middle-aged(void *object_pointer); void *operator geriatric(void *object_pointer); void *operator corpse(void *object_pointer); Each of these should have instances for static, auto, and extern. I can't really justify the behavior of these operators, nor do I want to talk about what they should do. I just want them defined in the language. My way. Now. Fred Flintstone President, Awful Language Designers, Inc.
marc@dumbcat.UUCP (Marco S Hyman) (10/30/89)
Fred Flintstone
President,
Awful Language Designers, Inc.
demands the addition of the following operators:
void *operator teenaged(void *object_pointer);
void *operator mature(void *object_pointer);
void *operator middle-aged(void *object_pointer);
void *operator geriatric(void *object_pointer);
void *operator corpse(void *object_pointer);
Each of these should have instances for static, auto, and extern.
It just goes to show that living in the stone age can turn a brain to mush.
Three other operators are just as important.
void *operator unborn(void *object_pointer);
void *operator infant(void *object_pointer);
void *operator child(void *object_pointer);
It would be impossible to write code without them. Of course, they must be
implemented MY way.
Barney Rubble,
Chief Technical Officer
Sensitive Softwarechase@Ozona.orc.olivetti.com (David Chase) (10/31/89)
In article <1989Oct26.191119.9278@polyslo.CalPoly.EDU> ttwang@polyslo.CalPoly.EDU (Thomas Wang) writes: >Currently there is no portable way to tell if a variable is >allocated as automatic, heap, static, or global. > >I propose that C++ be extended to support the following new operators: > [proposal deleted]. Basically, I think you're crazy to try to put garbage collection into C++, but I wish you luck. Language changes are probably not a good idea, even if you are right and everyone else is wrong. I also suspect that you'll have an interesting time figuring out which destructors to invoke where in a garbage-collected system -- have you considered, for example, cyclic garbage? You can probably solve most of your (sub)problem here by getting deeply in bed with the storage allocator. For instance, the Boehm-Weiser conservative collector "knows" what memory it is managing, and it is possible to tell if a pointer is "real" or not. Similarly, objects on the stack (I assume this is what you mean by automatic) are obvious because their addresses point into the range between stack-base and current sp. Static and global are indistinguishable, but those objects are all allocated between "end" and the base of the data segment (some machines have separate non-contiguous segments for text and data -- obviously, this generalizes). You might give the Boehm-Weiser collector a look; within it are parameters describing many different machines. You can either adapt their collector to your purposes, or you can use their parameters in your collector. Here's how to get it: (9)% ftp titan.rice.edu Connected to titan.rice.edu. 220 titan FTP server (SunOS 4.0) ready. Name (titan.rice.edu:chase): anonymous 331 Guest login ok, send ident as password. Password: 230 Guest login ok, access restrictions apply. ftp> cd public 250 CWD command successful. ftp> dir gc* 200 PORT command successful. 150 ASCII data connection for /bin/ls (129.189.192.6,1211) (0 bytes). -rw-r--r-- 1 211 30 56720 Oct 13 17:53 gc.shar.01 -rw-r--r-- 1 211 30 54253 Oct 13 17:53 gc.shar.02 226 ASCII Transfer complete. remote: gc* 132 bytes received in .28 seconds (.46 Kbytes/s) ftp> This collector can be tuned and tweaked to varying degrees of conservativeness, but in its most conservative form (pointers can appear at any alignment, and any pointer into an object's interior also counts as a pointer to the object) collection is much slower and has on occasion failed to reclaim noticeable amounts of memory. There's additional problems if your compiler has a "real" optimizer, but that usually isn't an issue for C. David
chase@Ozona.orc.olivetti.com (David Chase) (10/31/89)
I previously posted, but two people have bugged me on this point, so I'll clarify it: >In article <1989Oct26.191119.9278@polyslo.CalPoly.EDU> ttwang@polyslo.CalPoly.EDU (Thomas Wang) writes: >>Currently there is no portable way to tell if a variable is >>allocated as automatic, heap, static, or global. >> >>I propose that C++ be extended to support the following new operators: >> [proposal deleted]. >You can probably solve most of your (sub)problem here by getting >deeply in bed with the storage allocator. For instance, the >Boehm-Weiser conservative collector "knows" what memory it is >managing, and it is possible to tell if a pointer is "real" or not. The Boehm-Weiser collector *cannot* tell if a given 32-bit value is a pointer, and integer, or your grandmother. It will assume it is a pointer. Since it does not do compaction, this is safe. This is what "conservative" means. I thought that was pretty clear, but apparently not. The point I was trying to make was: If you present it with a 32-bit value and promise that the value is in fact a Pointer, then it can tell you whether it allocated that particular pointer, how large the addressed object is, and whether it might contain pointers (i.e., whether the atomic or composite object allocator was used to obtain it). Similar techniques can be used to determine if a pointer addresses the stack segment, the text segment, or the data segment. I believe that this solves Thomas Wang's problem. He wasn't asking "is it a pointer"; he was asking "what kind of pointer is this". David