Каковы различия между Дженериками в C# и Java … и Шаблоны в C++? [закрытый]

Похож, среди других очень интересных предложений, существует один о совершенствовании дженериков и повреждении назад совместимость:

В настоящее время, дженерики реализованы с помощью стирания, что означает, что универсальная информация о типе не доступна во времени выполнения, которое делает некоторый код трудно для записи. Дженерики были реализованы этот способ поддерживать назад совместимость с более старым неуниверсальным кодом. Овеществленные дженерики сделали бы универсальную информацию о типе доступной во времени выполнения, которое повредит неуниверсальный код прежней версии. Однако Neal Gafter предложил делать типы reifiable, только если указанный, чтобы не повредить обратную совместимость.

в статья Alex Miller о Java 7 Предложений

В Java дженерики являются уровнем компилятора только, таким образом, Вы добираетесь:

a = new ArrayList<String>()
a.getClass() => ArrayList

Примечание, что тип списка массива, не списка строк. Таким образом, тип списка бананов равнялся бы () списку обезьян.

Так сказать.

Шаблоны C++ на самом деле намного более мощны, чем их C# и дубликаты Java, поскольку они оценены во время компиляции и поддерживают специализацию. Это допускает Шаблонное Метапрограммирование и делает компилятор C++ эквивалентным Машине Тьюринга (т.е. во время процесса компиляции можно вычислить что-либо, что вычислимо с Машиной Тьюринга).

Википедия имеет большие рецензии, выдерживающие сравнение и дженерики Java/C# и Дженерики/C++ Java шаблоны. основная статья о Дженериках кажется немного нарушенной, но она действительно имеет некоторую хорошую информацию в нем.

Самая большая жалоба является стиранием типа. В этом дженерики не осуществляются во времени выполнения. Вот ссылка на некоторые документы Sun о предмете .

Дженерики реализованы стиранием типа: универсальная информация о типе присутствует только во время компиляции, после которого она стирается компилятором.

И Java и C# представили дженерики после их первого выпуска языка. Однако существуют различия в том, как оперативные библиотеки изменились, когда дженерики были представлены. дженерики C# не являются просто волшебством компилятора и таким образом, это не было возможно к generify существующие классы библиотеки, не повреждая назад совместимость.

, Например, в Java существующее Платформа Наборов была полностью genericised. Java не имеет и универсальной и неуниверсальной версии прежней версии классов наборов. До некоторой степени это намного более чисто - если необходимо использовать набор в C# существует действительно очень мало причины пойти с неуниверсальной версией, но те классы прежней версии остаются на месте, загромождая среду.

Другими заметными различиями являются Классы Enum в Java и C#. Перечисление Java имеет это несколько извилисто выглядящее определение:

//  java.lang.Enum Definition in Java
public abstract class Enum<E extends Enum<E>> implements Comparable<E>, Serializable {

(см. Angelika Langer, очень ясную объяснение точно, почему это так. По существу это означает, что Java может предоставить безопасный с точки зрения типов доступ от строки до ее Перечисления значений:

//  Parsing String to Enum in Java
Colour colour = Colour.valueOf("RED");

Сравнивают это с версией C#:

//  Parsing String to Enum in C#
Colour colour = (Colour)Enum.Parse(typeof(Colour), "RED");

, Поскольку Перечисление уже существовало в C#, прежде чем дженерики были представлены языку, определение не могло измениться, не повреждая существующий код. Так, как наборы, это остается в оперативных библиотеках в этом состоянии прежней версии.

Продолжение моей предыдущей регистрации.

Шаблоны являются одной из главных причин, почему C++ перестал работать так плачевно в intellisense, независимо от используемого IDE. Из-за шаблонной специализации IDE никогда не может быть действительно уверен, существует ли данный участник или нет. Рассмотрите:

template <typename T>
struct X {
    void foo() { }
};

template <>
struct X<int> { };

typedef int my_int_type;

X<my_int_type> a;
a.|

Теперь, курсор в обозначенном положении, и это чертовски трудно для IDE для высказывания в той точке, если, и что, имеют участники a. Для других языков парсинг был бы прост, но для C++, довольно мало оценки необходима заранее.

Это ухудшается. Что, если my_int_type были определены в шаблоне класса также? Теперь его тип зависел бы от другого аргумента типа. И здесь, даже сбой компиляторов.

template <typename T>
struct Y {
    typedef T my_type;
};

X<Y<int>::my_type> b;

После небольшого количества взглядов, программист пришел бы к заключению, что этот код совпадает с вышеупомянутым: Y<int>::my_type твердость к int, поэтому b должна быть тем же типом как a, правильно?

Неправильно. В точке, где компилятор пытается разрешить этот оператор, он еще на самом деле не знает Y<int>::my_type! Поэтому это не знает, что это - тип. Это могло быть что-то еще, например, функция членства или поле. Это могло бы дать начало неоднозначностям (хотя не в данном случае), поэтому компилятор перестал работать. Мы должны сказать ему явно, что обращаемся к имени типа:

X<typename Y<int>::my_type> b;

Теперь, компиляции кода. Чтобы видеть, как неоднозначности являются результатом этой ситуации, рассмотрите следующий код:

Y<int>::my_type(123);

Этот оператор кода совершенно допустим и говорит C++ выполнять вызов функции к [1 111]. Однако, если бы my_type не функция, а скорее тип, этот оператор все еще был бы допустим и выполнил бы специальный бросок (бросок функционального стиля), который часто является вызовом конструктора. Компилятор не может сказать, который мы имеем в виду, таким образом, мы должны снять неоднозначность здесь.

Уже существует много хороших ответов на , каковы различия, таким образом позвольте мне дать немного отличающуюся перспективу и добавьте почему .

, Как был уже объяснен, основное различие стирание типа , т.е. то, что компилятор Java стирает универсальные типы и они не заканчивают в сгенерированном байт-коде. Однако вопрос: почему кто-либо сделал бы это? Это не имеет смысла! Или он?

ну, какова альтернатива? Если Вы не реализуете дженериков на языке, где делают , Вы реализуете их? И ответ: в Виртуальной машине. Который повреждает назад совместимость.

стирание Типа, с другой стороны, позволяет Вам смешивать универсальные клиенты с неуниверсальными библиотеками. Другими словами: код, который был скомпилирован на Java 5, может все еще быть развернут на Java 1.4.

Microsoft, однако, решила повредить назад совместимость для дженериков. Это , почему Дженерики.NET "лучше", чем Дженерики Java.

, Конечно, Sun не является идиотами или трусами. Причина, почему они "пошли на попятный", состояла в том, что Java был значительно более старым и более широко распространенным, чем.NET, когда они представили дженерики. (Они были представлены примерно одновременно в обоих мирах.) Повреждающий назад совместимость была бы огромная боль.

Помещенный еще один путь: в Java Дженерики являются частью Язык (что означает, что они применяются [только 116] к Java, не к другим языкам), в.NET, они - часть Виртуальная машина (что означает, что они относятся весь языки, не только C# и Визуальный Basic.NET).