Re: C++ generics

firstly, thanks for all the amazing info you provided.

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.

this has to do a lot with the design of the languages. i can definitely not comment on generics in c++. but i am very relieved with the constraints part in java/c#. one part in generics that was really confusing me was that how can i know what "type" the generic class will have to work with so that some important/basic common property can be worked on. in other words, since i can constraint the generic to IComparable ( i guess == Comparable in java) it is much simpler to understand how a sorting algorithm can be created.

how do such things work in c++? do you just hope that the class used overloads some operator or something. else generate a compile error? say for the same sorting algorithm, is there some basic comparison method/operator the class is to define. is there no way to "constraint" that?


Anyway, so Eckel is saying if you have these constraints why bother with generics? What dyou feel he was saying?

why do i even need to bother with bruce, when i have mohn here!! if he was saying constraints are not a good thing, then i differ.


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 .. 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.

i have not read the vm spec, so the info yu provided was new to me. so thanks again for more info again!!

as yu know in java each class has to be in a seperate .java and hence goes into a seperate .class file. in .net yu can have multiple classes in a simgle file. so i am guessing that it was thought better to seperate all the type info of all classes into a seperate metadata layer, and leave the actual code in the IL layer. the vm spec for class files you showed has been present pre java 1.5. so the type info has always been there.

but the metadata introduced in java 1.5 was not type info. the example provided was equivalent to the attributes in .net. so this was what i was trying to say.


Attributes enbales you to generate more custom (you can create your own) info like this.

then i saw some stuff on metadata in java..
"The Metadata feature in J2SE 1.5 provides the ability to associate additional data alongside Java classes, interfaces, methods, and fields. This additional data, or annotation, can be read by the javac compiler or other tools, and depending on configuration can also be stored in the class file and can be discovered at runtime using the Java reflection API.""

this is what you were saying. so i guess i goofed up again.!! :) . so metadata means adding more type info other than the general class stuff.

i am coming to questions on metadata/attributes now. how do they work? there is additional metadata present so does the vm link this to the implementations at runtime or what?

also if you ever get any info on how generics have been implemented in java pls let me know. compiler-casting, i hope is an over simplification by me...