C++은 세상에 존재하는 모든 기능을 포함하려고 했기 때문에 극도로 복잡한 언어가 되었다. 개체 지향 기능과 C와의 호환성, 그리고 템플릿을 통한 일반화 프로그래밍까지의 특징을 포함했기 때문에, 엄청나게 복잡하다. 그래도 가장 괜찮고, 발전성이 있는 기능을 꼽으라고 한다면 단연 템플릿이 될 것이다. C++의 혁명적인 STL은 바로 템플릿의 일반화 기능에서 온 것이며, 이것은 일반화 프로그래밍이 가능한 실제적인 구현물이기도 하다. C++의 템플릿은 처음에는 매크로 기능을 크게 벗어나지 못했지만, 점차 템플릿 특수화(template specialization)와 같은 특징이 포함되면서 온갖 트릭을 가능하게 되었으며, 이것은 boost의 MPL(Meta Programming Library)이라는, 컴파일 시점에서 STL과 같은 라이브러리 구현이 가능하다는 것을 보여주었다.
그런데 C#의 제네릭의 경우에는, 확실히 C++의 템플릿보다 유연성이 떨어진다. 하지만 이것은 언어 자체의 단점으로 보이지 않는다. C++의 템플릿이 이런 유연함을 가질 수 있는 이유 중 하나는, 실제로 코드 내에서 실행되기 전까지는 인스턴스화되지 않고, 다만 문법의 적법성만 검사한다는 특징 때문이다. 이러한 특징 때문에 템플릿은 메타 코드로서의 동작이 가능해졌다(물론, 이것 때문에 export란 키워드를 제대로 구현한 컴파일러는 매우 드물며, export라는 기능을 구현하는 것은 템플릿 전문화 구현 이상의 복잡하다고 알려져 있다). C#처럼 강력한 타입 검사를 하는 언어에서는, 알려져 있지 않은 타입에 대한 메서드 호출은 원천적으로 가능해보이지 않기 때문이다.
다시 말해서, 메타 프로그래밍의 관점에서 본다면 C#의 제네릭 기능은 현재로서는 꽝이다. 하지만, 메타 프로그래밍의 가능성을 제외한다면 강력한 타입 체크를 거치는 C#의 제네릭 기능은 제한적이지만 훌륭히 원하는 기능을 수행할 수 있을 것이다.
그런데 C#의 제네릭의 경우에는, 확실히 C++의 템플릿보다 유연성이 떨어진다. 하지만 이것은 언어 자체의 단점으로 보이지 않는다. C++의 템플릿이 이런 유연함을 가질 수 있는 이유 중 하나는, 실제로 코드 내에서 실행되기 전까지는 인스턴스화되지 않고, 다만 문법의 적법성만 검사한다는 특징 때문이다. 이러한 특징 때문에 템플릿은 메타 코드로서의 동작이 가능해졌다(물론, 이것 때문에 export란 키워드를 제대로 구현한 컴파일러는 매우 드물며, export라는 기능을 구현하는 것은 템플릿 전문화 구현 이상의 복잡하다고 알려져 있다). C#처럼 강력한 타입 검사를 하는 언어에서는, 알려져 있지 않은 타입에 대한 메서드 호출은 원천적으로 가능해보이지 않기 때문이다.
다시 말해서, 메타 프로그래밍의 관점에서 본다면 C#의 제네릭 기능은 현재로서는 꽝이다. 하지만, 메타 프로그래밍의 가능성을 제외한다면 강력한 타입 체크를 거치는 C#의 제네릭 기능은 제한적이지만 훌륭히 원하는 기능을 수행할 수 있을 것이다.