4. VS.NET 7.1 dazu bringen normale Java-Programme zu erstellen

VS.NET 7.1 dazu bringen normale Java-Programme zu erstellen

  • H

    Die Generics sind auch weniger flexibel, sie sind auf das beschränkt, was auch C# kann.

    Also so primitive Dinge, wie Generics zur Laufzeit instanzieren? Das kann ich nichtmals in C++ 😮

    0
  • ?

    Technisch sind sie IMHO auch top. Aber sprachlich nicht. Kennst du noch die 4 Varianztypen, über die wir letztens gesprochen haben? C# kann das nicht.

    Ich finde das aber eigentlich sehr nützlich und habe das tatsächlich schon ein paar mal gebraucht.

    Dagegen war ein anderes Feature von C# in der Praxis bisher für mich nicht einsetzbar: Die Nutzung von value types, was mich eigentlich sehr gereizt hätte. Mich reizt aber ein int/long nur noch halb so viel, wenn ich kein '+' benutzen kann und im Moment kann man keine statischen Methoden als constraint verwenden. Irgendwie ist dort auch wie vieles in C# nur halb zu Ende gedacht worden.
    Ich hätte ein generisches Point-struct gebraucht, einmal mit int und einmal mit long. Jetzt hab ichs nicht-generisch für beide Fälle mit long gemacht. Sicher kein Beinbruch, aber ich hätte mir schöneres vorstellen können.

    Das einzige, was für mich echt reizvoll ist, da hast du Recht, ist

    class Test<T>
{
    public T[] createArray(int count)
    {
        return new T[count];
    }
}

    Java suckt dagegen in dieser Hinsicht:

    class Test<T>
{
	public static void main(String[] args)
	{
		Test<Integer> test = new Test<Integer>();

		// *PENG*
		Integer[] array = test.createArray(10);
		array[5] = 3;
	}

	public T[] createArray(int count)
	{
		return (T[])(new Object[count]);
	}
}

    Wenigstens kann man aber sein zurückgeliefertes T[] benutzen und Ts reinstecken und auslesen.

    Für Sachen wie Standardkonstruktor von T (C#) hab ich dagegen im Moment noch keine Verwendung gefunden.
    Wenn ich mir jetzt aber vorstellen würde, Java würde mit den Generics technisch von vorne anfangen, die coolen Features, die es aber jetzt schon hat, behalten... *sabber*

    So bleibt mir nur die Erkenntnis, dass die C#-Leute sich eigentlich eine Chance verbaut haben, während die Java-Leute das bestmögliche aus ihrer Situation gemacht haben.

    0
  • A

    So bleibt mir nur die Erkenntnis, dass die C#-Leute sich eigentlich eine Chance verbaut haben, während die Java-Leute das bestmögliche aus ihrer Situation gemacht haben.

    was ist das denn für ein Quatsch. Die Implementierung von Generics kann genau wie in Java auch nachträglich geändert werden. Es hat sich, genau wie in Java, niemand was verbaut.

    0
  • ?

    Die Implementierung bei C# müsste IMHO nicht geändert werden, sondern die Sprache.
    Du kannst eine Sprache nicht beliebig ändern, nicht im Nachhinein. Was meinst du, warum C++ so ein geniales Übersetzungsmodell hat und Java kein "vernünftiges" override mehr kriegt?
    Nur bei C# hatte man die Chance, die Generics wirklich gut zu machen und jetzt fehlen viele Features. Vielleicht bin ich aber auch vorschnell. Ergänzungen an Sprachen hat es öfter schon gegeben, vielleicht besteht die schwache Hoffnung, dass das noch was wird. Ich würde es mir jedenfalls wünschen.

    Bei Java müsste man auf jeden Fall mit vorhandenem Bytecode brechen, oder eine VM für viele Plattformen, vielen Prozessorarchitekturen und zwei verschiedenen Bytecode-Formaten bauen...

    0
  • *

    Hi!

    Helium schrieb:

    Die Generics sind auch weniger flexibel, sie sind auf das beschränkt, was auch C# kann.

    Also so primitive Dinge, wie Generics zur Laufzeit instanzieren? Das kann ich nichtmals in C++ 😮

    Ist das dein Ernst? Ich weiss jetzt nicht so recht wie ich das verstehen soll, aber generics zur Laufzeit instanzieren geht doch 🙄 ?

    Was die constraints mit statischen Methoden betrifft, gibt es irgendwo auf der Microsoft Homepage einen Antrag, wo man sich eintragen lassen kann. Das ist dort, wo auch die anderen Vorschläge sind, aber man muss sich registrieren. Gerade weil man nur instanzmember vorgeben kann, bin ich ein wenig von den Generics weggekommen. Mit normalen templates kommt man im neuen C++ einfach weiter. Vor einiger Zeit habe ich mir einige Klassen geschrieben, die die operatoren für T zur Laufzeit implementieren (kleine automatisch generierte Funktionen die op_Addition aufrufen, oder ldarg.0 ldarg.1 add ret halt), was mir dann aber syntaktisch zu dumm wurde. Es wäre auch langsammer gewesen, da richtige Funktionsaufrufe anstelle von Operatoren gewesen wären. Und genau hier liegt glaub ich das Problem. Ein operator+ wird zur Compile-Zeit aufgelöst. Dabei entsteht folgendes:

    Bei System.Int32:

ldarg.0
ldarg.1
add
ret

Bei System.Decimal

ldarg.0
ldarg.1
call die blub op_Addition bei System.Decimal
ret

    Einmal ist es ein Funktionsaufruf, mal nicht! Das als constraint zu implementiern ist ihnen wohl zu schwer.

    0
  • ?

    Ich glaube das grundlegendere Problem liegt woanders. Du kannst ja für deine eigenen Typen auch nen op+ schreiben, der dann letztlich ein Funktionsaufruf ist. Für int ist es halt ne besonderheit, intern im .Net Framework.
    Das Problem liegt ganz einfach darin, dass Interfaces keine statischen Methoden vorgeben können, wie der op+ eine ist.

    @AndreasW: Vielleicht kann ich dir hiermit deutlicher machen, was ich vermisse:
    http://java.sun.com/j2se/1.5.0/docs/api/java/util/Arrays.html#sort(T[], java.util.Comparator)
    Diese Methode sortiert ein Array mit Elementtyp T, der Comparator muss aber nicht ein Comparator<T> sein, sondern kann auch ein Comparator<Basisklasse von T> sein. Das kann schon sinnvoll sein, denn vielleicht ist T von einer Klasse abgeleitet, für die schon ein Comparator geschrieben ist, der für T auch noch passend ist.
    Auf so etwas kann man öfter mal stoßen (nicht nur beim Vergleichen), wenn man es kennt, lernt man es zu schätzen, zumindest ich.

    0
Anmelden zum Antworten