Re: Unified Type System

I was thinking of garbage collection myself and I do think a common base is required that keeps say two things, a count and a vector of pointers (or references) to the objects created, at the very minimum.

That very well could be one implementation. The pointers to objects created on the heap are on the stack. So, dyou think it would be economical for the garbage collector to also have pointers to those objects?

In .NET, when a collection is invoked, it walks through the roots (ie. global, static and stack pointers) recursively and creates a graph. This signifies all reachable objects. The non-reachable objects (ie. garbage) are marked. Those marked objects are deleted after the graph has been created. The others are compacted.

That mark phase... The Object base class could play a role. As I said last time, there could be some flag in Object thats set signifying that it's garbage and should be deleted. The other way could be that the collector creates a table of pointers to just the garbage objects to delete. In that case, we wouldn't need that base class with the flag.

The other reason why I feel having Object as the base class is not directly connected to garbage collection is cause MFC also has a root CObject class. I'm not very knowlegable about MFC, but if you want to "play well" with the framework and use your objects in the collections, you need to derive from CObject.

I guess Rahul might be on the right track regarding having those common methods in all objects. But I'm still not totally convinced.

Generics in C++ essentially auto-generate the classes based on type?

Yup. Templates - It's all done at compile-time. If the compiler comes across a declaration of the template with a type, it will auto-generate the class based on the type. And then that class is compiled. Dinesh can you confirm this?

What do you think happens in Java/.NET Generics? I suppose they 'fortified' the current Collections by forcing Type. This reduces Casting troubles at run-time and also provides better perf. So I think Generics are as dependent on Object.

As I understand it, in .NET, when the compiler comes across a declaration of a generic class with a value type (primitives, structs), it creates a new class definition. But it will only create one class definition for all reference types. This is because it holds references, which are the same regardless of what type it's pointing to.

So for example, if you have
ArrayList<int> intList = new ArrayList<int>();
ArrayList<double> doubleList = new ArrayList<double>();

ArrayList<string> stringList = ArrayList<string>();
ArrayList<MyClass> myClassList = ArrayList<MyClass>();

This code will create only three class definitions - One for int, one for double and one for references. The references definition will be used for both string and MyClass.

I believe Java will spit out four definitions.

You seem to have agreed with the importance of the other methods. toString( ), clone( ) and equals( ) are not the most important, but are pretty useful in many cases. Placing them in Object must have been thought over.

Actually, I just gave those methods as examples. I was talking about all of them. I realize they were thought over a lot. The guys who designed these systems are geniuses. I'm just trying to understand if that really was the reason for having a Unified Type System.