One must also keep in mind that generics are not at all equivalent to C++ templates or even Java generics (type erasure!). Some of the major annoyances with the platform have just recently (.NET 4) been fixed (like co- and contravariance issues with generic collections and enumerations).

I could expect it, given that the two objects should have both identical code and data, and one has an interface that is a subset of the other. The fact that it's so difficult to use one in place of the other is just a limitation imposed by poor design choices in the C++ template system.

Actually it is the result of a powerful C++ design choice: template specializations.

If it C++ disallowed atrocities like this, the types would be compatible:

struct MyObject{};
template struct MyTemplateClass {
T x;
};
template<> struct MyTemplateClass<const MyObject*>{};
int main()
{
MyObject obj;

MyTemplateClass<MyObject*> i1;
i1.x= &obj;

MyTemplateClass<const MyObject*> i2;
i2.x= &obj; // compile error
}


It seems it would be a pretty silly tradeoff to disallow template specializations in order to allow implicit template type conversions, particularly when the solution to your original problem is so simple:


template<typename ContainerT>
void function(const ContainerT&){}


It seems it would be a pretty silly tradeoff to disallow template specializations in order to allow implicit template type conversions, particularly when the solution to your original problem is so simple:


template<typename ContainerT>
void function(const ContainerT&){}


That would be a reasonable solution if it did not have such a dramatic impact on compilation time, and if it did not require major workarounds to apply to virtual functions.

There are definite advantages to the restrictions C# imposes on its generics.

That would be a reasonable solution if it did not have such a dramatic impact on compilation time, and if it did not require major workarounds to apply to virtual functions.

There are definite advantages to the restrictions C# imposes on its generics.

That should have little impact on compile times. Certainly not "dramatic."

And yes, there are definite advantages to the restrictions C# imposes on it's generics. There are also definite disadvantages. A major design focus behind C# is in fact compile times and convenience, whereas C++ focuses more on flexibility and run-time performance. Template specialization is a big part of that. It's certainly not a design flaw. And the workarounds you're talking about in regards to virtual functions are typically only necessary if you use questionable design choices in your own code from the perspective of C++, with modern C++ absolutely favoring generics and generic algorithms over inheritance and virtual functions, especially when it comes to operating on template types.

[quote name='Mike.Popoloski' timestamp='1348882742' post='4984924']
The relatively coarse-grained nature of generic constraints in C# / the CLI is my biggest annoyance with the platform. There's really no reason why the compiler couldn't infer method (and operator!) and property level constraints and simply require that all type arguments provide them.

As far as I can tell, the reason C# generics have the limitations they do is because they can be deployed in DLLs. This means that the compiled generic must work both for existing 'T' as well as unknown types that someone may cook up in the future (as long as those types fulfill all of the constraints the generic specifies). The compiler ensures that the generic can be used by anything that supports those constraints, without needing to actually be instantiated like C++ templates.

This is both their greatest strength and the cause of all of their weaknesses.
[/quote]Though there is another potential design decision that would enable this, which would be to allow interface implementation to be implicit. For example, if you're like me and wanted to write a generic structure that does math of some kind [for example, a vector class], it'd be nice if all you had to do was specify that said object implemented an interface that exposed an add, multiply, divide, and a negate function. The compiler can infer the existence of an interface that has these properties simply enough [or maybe even demand that you implement the interface to make it additionally explicit]. The missing link is to be able to take a type, notice that it has an add, multiply, divide, and a negate function, and deduce that it implicity satisfies that interface.

In fact, the lack of this, and the lack of explicit extension-method style fitting an existing type into a new interface, is what really prevents things like generic matrix classes. This is entirely do-able though, and is something you can wedge into a DLL without much issue.

Though there is another potential design decision that would enable this, which would be to allow interface implementation to be implicit.

C# and .Net 4.0 have their own implementation which allows this. It's called 'dynamic typing'.

Anonymous interfaces (one interface per member signature for every type) would be bad, because it would allow unintentional access of that interface, which would lead to bugs.

It would also hinder someone from learning your codebase. Anyone working on a large team will tell you that the bulk of their job isn't writing new code, it's learning what everyone else's code does. The more things in a language that are left unstated, the easier it is for someone to overlook some hidden behavior of the code.