Re: C++ generics

you must have noticed the "Insights Into the .NET Architecture" series on artima. they did mention some stuff of multiple inheritance being implemented in the CLR/CLS

Yeah I did read that article. I guess Eiffel has implemented MI, but it doesn't "play well" will the other languages in .NET. As in, if you have a multi language project with subclassing from one language to another, then Eiffel won't work cause MI isn't in the CLS.

could you please put the bruce eckel blog on java generics in simpler language!!

Basically, C++ Templates != C#/Java Generics. Both of them have similar goals, but not exact same capabilities. C++ offers more freedom in what types you can use when instantiating a template class. In a previous post I had written a bit about constraints in C# (there is something similar in Java also).

You CANNOT use ANY type you want when instantiating a generic class. In C++ you CAN. The constraints in C#/Java are there to enforce type safety. Generally they are an Interface or Base Class. It means "instantiate this generic class/method with a type ONLY if it implements this interface or extends this Base Class".

Ex...

public T Max<T>( T x, T y ) where T : IComparable
{
    // Call ONLY IComparable methods on x and y

    if ( x.CompareTo( y ) > 0 )
    {
        return x;
    }
    else
    {
        return y;
    }
}

or

public void Foo<T>( T bar ) where T : MyBaseClass
{
    // Call ONLY MyBaseClass methods on bar
}

Anyway, so Eckel is saying if you have these constraints why bother with generics? Just use Interfaces or Base Classes directly instead of making a generic class and then telling the user to ONLY instantiate that class with a type that implements that interface or extends the base class. Atleast that's the meaning I got from it. What dyou feel he was saying?

I think there is a slight difference between JUST Interfaces vs Interfaces through Generics...

With Interfaces, the compiler just cares about the methods on the interface. It does NOT care about the underlying type. As in if class Dog and class Cat both implement interface IAnimal, the compiler won't distinguish between the two if you have an IAnimal reference to a Dog object or a Cat object...

private void DoSomethingWithAnimals( IAnimal x )
{
    ...
}

IAnimal animal;

animal = new Dog();

DoSomethingWithAnimals( animal ); // fine

animal = new Cat();

DoSomethingWithAnimals( animal ); // fine

But with interfaces through generics it DOES care...

private void DoSomethingWithAnimals<T>( T x ) where T : IAnimal
{
    ...
}

IAnimal animal;

animal = new Dog();

DoSomethingWithAnimals<Dog>( animal ); // fine

animal = new Cat();

DoSomethingWithAnimals<Dog>( animal ); // fails

This is how I think of it. So with generics, you are not only limited by the interface, but also the type that implements the interface.

there is no metadata layer in a .class file. metadata in java == attributes in c#. so metadata in java is just injection of bytecode based on the implementation by the compiler.

I did a search for Java .class files and got this... http://java.sun.com/docs/books/vmspec/2nd-edition/html/ClassFile.doc.html

It talks about storing the type information just like in .NET. The terminology might be different (.NET uses metadata for pretty much everything in the assembly aside from IL) but they DO store all the info in the file. Check it... I didn't go through in detail, but saw stuff like...

methods[]
Each value in the methods table must be a method_info (§4.6) structure giving a complete description of a method in this class or interface. If the method is not native or abstract, the Java virtual machine instructions implementing the method are also supplied.

The method_info structures represent all methods declared by this class or interface type, including instance methods, class (static) methods, instance initialization methods (§3.9), and any class or interface initialization method (§3.9). The methods table does not include items representing methods that are inherited from superclasses or superinterfaces.

This is saying the .class file holds info about each method defined in the class in the "methods" array.

See, all this type info HAS to be there for Reflection to work. How else will the runtime access this data? Attributes enbales you to generate more custom (you can create your own) info like this. All other type data is generated by default by the compiler.