Jakie są różnice między generykami w C# i Javie... a szablonami w C++? [zamknięte]

C++ rzadko używa terminologii "generics". Zamiast tego słowo" szablony " jest używane i jest bardziej dokładne. Szablony opisują jedną technikę , aby uzyskać ogólny projekt.

Szablony C++ bardzo różnią się od tego, co implementują zarówno C#, jak i Java z dwóch głównych powodów. Pierwszym powodem jest to, że szablony C++ nie pozwalają tylko na argumenty typu compile-time, ale także argumenty const-value: szablony mogą być podane jako liczby całkowite lub nawet podpisy funkcji. Oznacza to, że może zrobić kilka ciekawych rzeczy w czasie kompilacji, np. obliczenia:

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;

Ten kod wykorzystuje również inną wyróżniającą się cechę szablonów C++, a mianowicie specjalizację szablonów. Kod definiuje jeden szablon klasy product, który ma jeden argument wartości. Definiuje również specjalizację dla tego szablonu, który jest używany, gdy argument jest ewaluowany do 1. To pozwala mi zdefiniować rekurencję nad definicjami szablonów. Sądzę, że po raz pierwszy odkrył to Andriej Alexandrescu .

Specjalizacja szablonów jest ważna dla C++ , ponieważ pozwala na różnice strukturalne w strukturach danych. Szablony jako całość to sposób na ujednolicenie interfejsu między typami. Jednakże, chociaż jest to pożądane, wszystkie typy nie mogą być traktowane jednakowo wewnątrz implementacji. C++ templates bierze to pod uwagę. Jest to taka sama różnica, jaką OOP robi między interfejsem a implementacją z nadrzędnością metod wirtualnych.

C++ szablony są niezbędne dla jego algorytmicznego paradygmatu programowania. Na przykład prawie wszystkie algorytmy dla kontenerów są zdefiniowane jako funkcje, które akceptują typ kontenera jako typ szablonu i traktują go jednolicie. Właściwie to nie jest to do końca prawda: C++ nie działa na kontenerach, ale raczej na zakresach , które są zdefiniowane przez dwa Iteratory, wskazujące początek i koniec kontenera. Tak więc cała zawartość jest ograniczona przez Iteratory: begin

Używanie iteratorów zamiast kontenerów jest użyteczne, ponieważ pozwala operować na częściach kontenera zamiast na całości.

Kolejną cechą wyróżniającą C++ jest możliwość częściowej specjalizacji dla szablonów klas. Jest to w pewnym sensie związane z dopasowywaniem wzorców na argumentach w Haskell i innych językach funkcyjnych. Na przykład, rozważmy klasę, która przechowuje elementy:

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

To działa dla każdego typu elementu. Ale powiedzmy, że my może przechowywać wskaźniki bardziej efektywnie niż inne typy, stosując jakąś specjalną sztuczkę. Możemy to zrobić poprzez częściowo specjalizując się dla wszystkich typów wskaźników:

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

Teraz, gdy przykładamy szablon kontenera dla jednego typu, używana jest odpowiednia definicja:

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

Sam Anders Hejlsberg opisał tutaj różnice " Generics in C#, Java, and C++".

Istnieje już wiele dobrych odpowiedzi na co różnice są, więc pozwól mi dać nieco inną perspektywę i dodać Dlaczego.

Jak już wyjaśniono, główną różnicą jest Type erasure, tzn. fakt, że kompilator Javy kasuje typy generyczne i nie kończą się one w wygenerowanym bajtowym kodzie. Jednak pytanie brzmi: Dlaczego ktoś miałby to zrobić? To nie ma sensu! A może tak?

A jaka jest alternatywa? Jeśli nie zaimplementować generyki w języku, gdzie Czy je implementujesz? A odpowiedź brzmi: w maszynie wirtualnej. Co łamie wsteczną kompatybilność.

Type erasure, z drugiej strony, pozwala na mieszanie klientów generycznych z bibliotekami nie-generycznymi. Innymi słowy: kod, który został skompilowany w Javie 5, nadal może być wdrożony w Javie 1.4.

Microsoft postanowił jednak zerwać wsteczną kompatybilność dla leków generycznych. to Dlaczego. NET Generics są "lepsze" niż Java Leki generyczne.

Oczywiście, Sun nie są idiotami ani tchórzami. Powodem, dla którego "stchórzyli", było to, że Java była znacznie starsza i bardziej rozpowszechniona niż.NET, kiedy wprowadzili generyki. (Zostały one wprowadzone mniej więcej w tym samym czasie w obu światach.) Złamanie kompatybilności wstecznej byłoby ogromnym bólem.

Inaczej mówiąc: w Javie Generyki są częścią języka (co oznacza, że stosują tylko do Javy, a nie do innych języków), w. Net są są częścią maszyny Wirtualnej (co oznacza, że mają zastosowanie do wszystkich języków , nie tylko C# i Visual Basic.NET).

Porównaj to z funkcjami. NET, takimi jak LINQ, wyrażenia lambda, wnioskowanie typów zmiennych lokalnych, typy anonimowe i drzewa wyrażeń: są to wszystkie funkcje języka . Dlatego istnieją subtelne różnice między VB.NET i C#: gdyby te funkcje były częścią maszyny wirtualnej, byłyby takie same w wszystkich językach. Ale CLR się nie zmienił: nadal jest tak samo w. NET 3.5 SP1 jak w. NET 2.0. Możesz skompilować program C#, który używa LINQ z kompilatorem. NET 3.5 i nadal uruchamiać go na. Net 2.0, pod warunkiem, że nie używasz żadnych bibliotek. NET 3.5. To by nie działało z generics i.NET 1.1, ale działałoby z Javą i Javą 1.4.

Kontynuacja mojego poprzedniego postu.

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

template <>
struct X<int> { };

typedef int my_int_type;

X<my_int_type> a;
a.|

Teraz, kursor znajduje się we wskazanej pozycji i cholernie trudno jest IDE powiedzieć w tym momencie, czy, i co, członkowie a mA. Dla innych języków parsowanie byłoby proste, ale dla C++, konieczna jest wcześniejsza ocena.

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

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

Po odrobinie zastanowienia programista doszedłby do wniosku, że ten kod jest taki sam jak powyższy: Y<int>::my_type rozwiązuje się na int, zatem b powinien być tego samego typu co a, prawda?

Źle. W momencie, gdy kompilator próbuje rozwiązać ten oświadczenie, to faktycznie nie wie Y<int>::my_type jeszcze! Dlatego nie wie, że jest to typ. Może to być coś innego, np. funkcja członka lub pole. Może to powodować niejasności (choć nie w tym przypadku), dlatego kompilator zawiedzie. Musimy powiedzieć wprost, że odwołujemy się do nazwy typu:

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

Teraz Kod się kompiluje. Aby zobaczyć, jak niejasności wynikają z tej sytuacji, rozważ następujący kod:

Y<int>::my_type(123);

To stwierdzenie kodu jest doskonale valid i każe C++ wykonać wywołanie funkcji do Y<int>::my_type. Jednakże, jeśli my_type nie jest funkcją, a raczej typem, to stwierdzenie to nadal będzie ważne i wykona specjalny rzut (rzut w stylu funkcji), który często jest wywołaniem konstruktora. Kompilator nie wie, co mamy na myśli, więc musimy tutaj disambiguate.

Zarówno Java, jak i C# wprowadziły generyki po pierwszym wydaniu języka. Istnieją jednak różnice w tym, jak podstawowe biblioteki zmieniły się po wprowadzeniu generics. generyczne C#to nie tylko magia kompilatora , więc nie było możliweuogólnienie istniejących klas bibliotecznych bez zerwania wstecznej kompatybilności.

Na przykład w Javie istniejący Framework Collections był całkowicie generyzowany. Java nie ma zarówno generic i legacy non-generic wersja klas kolekcji. pod pewnymi względami jest to o wiele czystsze - jeśli potrzebujesz użyć kolekcji w C#, naprawdę nie ma powodu, aby korzystać z niestandardowej wersji, ale te starsze klasy pozostają na swoim miejscu, zaśmiecając krajobraz.

Inną zauważalną różnicą są klasy Enum w Javie i C#. Enum Javy ma tę nieco krętą definicję:

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

(patrz Angelika Langer ' s very clear wyjaśnienie, dlaczego tak jest. Zasadniczo oznacza to, że Java może nadać typowi bezpieczny dostęp z ciągu znaków do jego wartości Enum:

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

Porównaj to z wersją C#:

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

Ponieważ Enum istniało już w C# Zanim generics został wprowadzony do języka, definicja nie mogła się zmienić bez złamania istniejącego kodu. Tak więc, podobnie jak zbiory, pozostaje w podstawowych bibliotekach w tym stanie Dziedzictwa.

11 miesięcy spóźnienia, ale myślę, że to pytanie jest gotowe na niektóre Java Wildcard rzeczy.

Jest to składniowa cecha języka Java. Załóżmy, że masz metodę:

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

I załóżmy, że nie musisz odwoływać się do typu T w ciele metody. Deklarujesz nazwę T i używasz jej tylko raz, więc po co wymyślać dla niej nazwę? Zamiast tego możesz napisać:

public void Foo(Collection<?> thing)

Znak zapytania prosi kompilator, aby udawał, że zadeklarowałeś normalny parametr o nazwie type to musi pojawić się tylko raz w tym miejscu.

Nie ma nic, co można zrobić z symbolami wieloznacznymi, czego nie można również zrobić z parametrem nazwanego typu (czyli jak te rzeczy są zawsze robione w C++ i C#).

Wikipedia ma świetne wyniki porównujące zarówno szablony Java/C# generics i Java generics/C++. Główny artykuł o generykach wydaje się nieco zaśmiecony, ale ma w sobie dobre informacje.

Największą reklamacją jest usunięcie typu. W tym przypadku generyki nie są egzekwowane w czasie wykonywania. Oto link do niektórych dokumentów Sun na temat.

Generyki są zaimplementowane według typu kasowanie: ogólne informacje o typie to obecny tylko w czasie kompilacji, po który jest usuwany przez kompilator.

Szablony C++ są w rzeczywistości znacznie potężniejsze niż ich odpowiedniki C# i Java, ponieważ są oceniane w czasie kompilacji i specjalizacji wsparcia. Pozwala to na Meta-Programowanie szablonów i sprawia, że kompilator C++ jest odpowiednikiem maszyny Turinga (tzn. podczas procesu kompilacji można obliczyć wszystko, co można obliczyć za pomocą maszyny Turinga).

W Javie generyki są tylko na poziomie kompilatora, więc otrzymujesz:

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

Zauważ, że typ ' a ' jest listą tablic, a nie listą łańcuchów. Typ więc listy bananów byłby równy () liście małp.

Wygląda na to, że wśród innych bardzo ciekawych propozycji jest jedna o dopracowaniu generyków i przełamaniu kompatybilności wstecznej:

Obecnie zaimplementowane są generyki za pomocą kasowania, co oznacza, że generic type information is not dostępne w czasie wykonywania, co sprawia, że niektóre kod trudny do napisania. Generics zostały wdrożone w ten sposób, aby wspierać kompatybilność wsteczna ze starszymi kod niestandardowy. Reified generics uczyniłoby Typ generyczny informacje dostępne w czasie wykonywania, który złamałby dziedzictwo nie-generyczne kod. Jednak Neal Gafter ma proponowane typy making reifiable only jeśli jest określony, tak aby nie złamać kompatybilność wsteczna.

At Artykuł Alexa Millera o Javie 7

NB: Nie mam wystarczająco dużo uwagi, aby skomentować, więc nie krępuj się przenieść to jako komentarz do odpowiedniej odpowiedzi.

Wbrew powszechnemu przekonaniu, którego nigdy nie rozumiem, skąd się wzięła,. NET zaimplementował prawdziwe generyki bez łamania wstecznej kompatybilności i poświęcili na to wyraźny wysiłek. Nie musisz zmieniać niestandardowego kodu.NET 1.0 na generics, aby być używanym w. Net 2.0. Zarówno listy generyczne, jak i nie generyczne są nadal dostępne w. Net framework 2.0 nawet do 4.0, dokładnie z powodu tylko wstecznej kompatybilności. Dlatego stare kody, które nadal używały nie-generycznej ArrayList, nadal będą działać i będą używać tej samej klasy ArrayList, co wcześniej. Kompatybilność kodu wstecznego jest zawsze utrzymywana od wersji 1.0 do teraz... Więc nawet w. Net 4.0, nadal musisz wybrać opcję, aby użyć dowolnej klasy non-generics z 1.0 BCL, jeśli zdecydujesz się to zrobić.

Więc nie sądzę, aby java musiała łamać wsteczną kompatybilność, aby wspierać prawdziwe generyki.