В чем разница между универсальными шаблонами в C# и Java ... и шаблонами в C++?

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

Сам Андерс Хейлсберг описал различия здесь «Дженерики в C#, Java и C++».

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

Generics are implemented by type erasure: generic type information is present only at compile time, after which it is erased by the compiler.

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

C++ редко использует терминологию «дженериков». Вместо этого используется более точное слово «шаблоны». Шаблоны описывает один техника для достижения универсального дизайна.

Шаблоны C++ сильно отличаются от того, что реализуют как C#, так и Java, по двум основным причинам. Первая причина заключается в том, что шаблоны C++ допускают не только аргументы типа времени компиляции, но также аргументы константного значения времени компиляции: шаблоны могут быть заданы как целые числа или даже сигнатуры функций. Это означает, что во время компиляции вы можете делать довольно забавные вещи, например расчеты:

template <unsigned int N>
struct product {
    static unsigned int const VALUE = N * product<N - 1>::VALUE;
};

template <>
struct product<1> {
    static unsigned int const VALUE = 1;
};

// Usage:
unsigned int const p5 = product<5>::VALUE;

Этот код также использует другую отличительную особенность шаблонов C++, а именно специализацию шаблонов. Код определяет один шаблон класса product с одним аргументом значения. Он также определяет специализацию для этого шаблона, которая используется всякий раз, когда аргумент оценивается как 1. Это позволяет мне определять рекурсию по определениям шаблонов. Я считаю, что это было впервые обнаружено Андрей Александреску.

Специализация шаблонов важна для C++, поскольку она допускает структурные различия в структурах данных. Шаблоны в целом - это средство унификации интерфейса между типами. Однако, хотя это желательно, все типы не могут обрабатываться одинаково внутри реализации. Это учитывается в шаблонах C++. Это почти то же самое различие, которое ООП делает между интерфейсом и реализацией с переопределением виртуальных методов.

Шаблоны C++ необходимы для его парадигмы алгоритмического программирования. Например, почти все алгоритмы для контейнеров определены как функции, которые принимают тип контейнера как тип шаблона и обрабатывают их единообразно. На самом деле, это не совсем так: C++ работает не с контейнерами, а с диапазоны, которые определяются двумя итераторами, указывающими на начало и конец контейнера. Таким образом, весь контент ограничен итераторами: begin

Использование итераторов вместо контейнеров полезно, поскольку позволяет работать с частями контейнера, а не с целым.

Еще одна отличительная черта C++ - возможность частичная специализация для шаблонов классов. Это в некоторой степени связано с сопоставлением с образцом аргументов в Haskell и других функциональных языках. Например, давайте рассмотрим класс, в котором хранятся элементы:

template <typename T>
class Store { … }; // (1)

Это работает для любого типа элемента. Но предположим, что мы можем хранить указатели более эффективно, чем другие типы, применяя специальный трюк. Мы можем сделать это, специализируясь на частично для всех типов указателей:

template <typename T>
class Store<T*> { … }; // (2)

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

Store<int> x; // Uses (1)
Store<int*> y; // Uses (2)
Store<string**> z; // Uses (2), with T = string*.

В Java универсальные шаблоны работают только на уровне компилятора, поэтому вы получаете:

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

Обратите внимание, что тип «a» - это список массивов, а не список строк. Таким образом, тип списка бананов будет равен () списку обезьян.

Так сказать.

Продолжение моей предыдущей публикации.

Шаблоны - одна из основных причин того, почему 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++ выполнить вызов функции Y<int>::my_type. Однако, если my_type не функция, а тип, этот оператор все равно будет действителен и выполнит специальное приведение (приведение в стиле функции), которое часто является вызовом конструктора. Компилятор не может сказать, что мы имеем в виду, поэтому мы должны устранить неоднозначность здесь.

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

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

Еще одно заметное отличие - это классы Enum в Java и C#. Java Enum имеет это несколько извилистое определение:

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

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

//  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");

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

Я добавлю свой голос к шуму и попытаюсь прояснить ситуацию:

C# Generics позволяют объявлять что-то подобное.

List<Person> foo = new List<Person>();

и тогда компилятор не позволит вам помещать в список вещи, не являющиеся Person. За кулисами компилятор C# просто помещает List<Person> в DLL-файл .NET, но во время выполнения JIT-компилятор создает новый набор кода, как если бы вы написали специальный класс списка только для содержания людей - что-то вроде ListOfPerson.

Преимущество этого в том, что он делает это очень быстро. Здесь нет приведения или каких-либо других вещей, и поскольку dll содержит информацию о том, что это список Person, другой код, который просматривает его позже с помощью отражения, может сказать, что он содержит объекты Person (так что вы получаете intellisense и так далее).

Обратной стороной этого является то, что старый код C# 1.0 и 1.1 (до того, как они добавили дженерики) не понимает эти новые List<something>, поэтому вам нужно вручную преобразовать вещи обратно в простой старый List, чтобы взаимодействовать с ними. Это не такая уж большая проблема, потому что двоичный код C# 2.0 не имеет обратной совместимости. Это произойдет только в том случае, если вы обновите старый код C# 1.0 / 1.1 до C# 2.0.

Java Generics позволяет вам объявить что-то подобное.

ArrayList<Person> foo = new ArrayList<Person>();

На первый взгляд это выглядит так же, как и есть. Компилятор также не позволит вам помещать в список вещи, не относящиеся к Person.

Разница в том, что происходит за кулисами. В отличие от C#, Java не создает специальный ListOfPerson - он просто использует старый добрый ArrayList, который всегда был в Java. Когда вы достаете вещи из массива, обычный танец кастинга Person p = (Person)foo.get(1); все еще должен быть выполнен. Компилятор избавляет вас от нажатия клавиш, но скорость нажатия / приведения все равно остается такой же, как и всегда. Когда люди упоминают «Type Erasure», они говорят именно об этом. Компилятор вставляет для вас приведение типов, а затем «стирает» тот факт, что это должен быть список Person, а не только Object.

Преимущество этого подхода в том, что старый код, который не понимает дженериков, не должен заботиться. Он по-прежнему имеет дело с тем же старым ArrayList, что и всегда. Это более важно в мире Java, потому что они хотели поддерживать компиляцию кода с использованием Java 5 с универсальными шаблонами и запускать его на старой версии 1.4 или предыдущих JVM, о чем Microsoft намеренно решила не беспокоиться.

Обратной стороной является снижение скорости, о котором я упоминал ранее, а также потому, что в файлах .class нет псевдокласса ListOfPerson или чего-либо подобного, кода, который просматривает его позже (с отражением или если вы вытащите его из другого коллекция, в которой он был преобразован в Object или так далее) никоим образом не может сказать, что это должен быть список, содержащий только Person, а не просто какой-либо другой список массивов.

Шаблоны C++ позволяют объявить что-то вроде этого

std::list<Person>* foo = new std::list<Person>();

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

Он имеет больше всего общего с дженериками C# в том, что он создает специальный pseudo-classes, а не просто отбрасывает информацию о типе, как это делает java, но это совершенно другой котел с рыбой.

И C#, и Java производят вывод, предназначенный для виртуальных машин. Если вы напишете код, в котором есть класс Person, в обоих случаях некоторая информация о классе Person будет помещена в файл .dll или .class, и JVM / CLR будет что-то делать с этим.

C++ производит необработанный двоичный код x86. Все является объектом нет, и нет базовой виртуальной машины, которая должна знать о классе Person. Нет упаковки или распаковки, и функции не обязательно должны принадлежать классам или чему-то еще.

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

В C# и Java системе универсальных шаблонов необходимо знать, какие методы доступны для класса, и передавать их виртуальной машине. Единственный способ сказать это - либо жестко запрограммировать реальный класс, либо использовать интерфейсы. Например:

string addNames<T>( T first, T second ) { return first.Name() + second.Name(); }

Этот код не будет компилироваться на C# или Java, потому что он не знает, что тип T на самом деле предоставляет метод с именем Name (). Вы должны сказать это - в C# вот так:

interface IHasName{ string Name(); };
string addNames<T>( T first, T second ) where T : IHasName { .... }

И затем вы должны убедиться, что вещи, которые вы передаете в addNames, реализуют интерфейс IHasName и так далее. Синтаксис java отличается (<T extends IHasName>), но имеет те же проблемы.

«Классический» случай этой проблемы - попытка написать функцию, которая делает это

string addNames<T>( T first, T second ) { return first + second; }

На самом деле вы не можете написать этот код, потому что нет способов объявить интерфейс с методом + в нем. Ты облажался.

C++ не страдает ни одной из этих проблем. Компилятор не заботится о передаче типов любой виртуальной машине - если оба ваших объекта имеют функцию .Name (), он будет компилироваться. Если они этого не сделают, этого не произойдет. Простой.

Итак, вот оно :-)

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

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

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

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

Однако Microsoft решила нарушить обратную совместимость для дженериков. Это, почему .NET Generics «лучше», чем Java Generics.

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

Иными словами: в Java Generics являются частью Язык (что означает, что они применяют Только к Java, а не к другим языкам), в .NET они являются частью Виртуальная машина (что означает, что они применяются к языкам все, а не только C# и Visual Basic.NET).

Сравните это с функциями .NET, такими как LINQ, лямбда-выражения, вывод типа локальной переменной, анонимные типы и деревья выражений: все это функции язык. Вот почему между VB.NET и C# есть тонкие различия: если бы эти функции были частью виртуальной машины, они были бы одинаковыми в языках все. Но среда CLR не изменилась: в .NET 3.5 SP1 она такая же, как и в .NET 2.0. Вы можете скомпилировать программу C#, которая использует LINQ, с компилятором .NET 3.5 и по-прежнему запускать ее на .NET 2.0, при условии, что вы не используете какие-либо библиотеки .NET 3.5. Тогда нет будет работать с дженериками и .NET 1.1, но бы будет работать с Java и Java 1.4.

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

Currently, generics are implemented using erasure, which means that the generic type information is not available at runtime, which makes some kind of code hard to write. Generics were implemented this way to support backwards compatibility with older non-generic code. Reified generics would make the generic type information available at runtime, which would break legacy non-generic code. However, Neal Gafter has proposed making types reifiable only if specified, so as to not break backward compatibility.

в Статья Алекса Миллера о предложениях Java 7

11 месяцев спустя, но я думаю, что этот вопрос готов для некоторых вещей Java Wildcard.

Это синтаксическая особенность Java. Предположим, у вас есть метод:

public <T> void Foo(Collection<T> thing)

И предположим, что вам не нужно ссылаться на тип T в теле метода. Вы объявляете имя T, а затем используете его только один раз, так почему вы должны придумывать для него имя? Вместо этого вы можете написать:

public void Foo(Collection<?> thing)

Знак вопроса просит компилятор сделать вид, что вы объявили параметр обычного именованного типа, который должен появляться в этом месте только один раз.

С подстановочными знаками вы ничего не можете сделать, чего нельзя сделать и с параметром именованного типа (именно так это всегда делается в C++ и C#).

NB: У меня недостаточно аргументов для комментариев, поэтому не стесняйтесь переместить это как комментарий к соответствующему ответу.

Вопреки распространенному мнению, откуда я никогда не понимаю, .net реализовал настоящие дженерики без нарушения обратной совместимости, и они приложили для этого явные усилия. Вам не нужно менять свой неуниверсальный код .net 1.0 на универсальный код только для использования в .net 2.0. И общие, и неуниверсальные списки по-прежнему доступны в .Net framework 2.0 даже до версии 4.0, только по причине обратной совместимости. Поэтому старые коды, которые все еще использовали неуниверсальный ArrayList, по-прежнему будут работать и будут использовать тот же класс ArrayList, что и раньше. Обратная совместимость кода всегда поддерживается с 1.0 до настоящего времени ... Так что даже в .net 4.0 вам все равно придется использовать любой не-общий класс из 1.0 BCL, если вы решите это сделать.

Поэтому я не думаю, что Java должна нарушать обратную совместимость для поддержки истинных дженериков.