C#, Java und Zeiger



  • DrZoidberg schrieb:

    Nochmal zur Klarstellung: Eine Variable kann niemals ein Objekt enthalten sondern immer nur eine Referenz oder einen Zeiger auf ein Objekt. Ein int dagegen ist kein Objekt und kann direkt in einer Variablen enthalten sein.

    Genau das ist der semantische Kuddelmuddel, diese völlig unnatürliche Unterscheidung zwischen eingebauten und selbstdefinierten Datentypen. Warum sagst du, ein int sei kein Objekt? Natürlich ist es eins! Wenn auch kein Objekt im Sinne von "Instanz einer Klasse". Und diese Unterscheidung ist absolut nicht einzusehen. C++ bemüht sich (wie ich finde mit Erfolg), möglichst keinen Unterschied zwischen den Datentypen zu machen.

    Die Konsequenzen sieht man auch an folgendem:

    T eins;
    T zwei;
    // ..... In Java: Initialisiere eins und zwei entsprechend ....
    eins = zwei;
    // Irgend eine geeignete Änderungn von zwei.
    // Welchen Wert hat eins, welchen zwei?!
    

    In Java macht es für diesen Code einen Unterschied, ob T ein eingebauter oder ein Klassentyp ist. Gilt ersteres, dann ist "eins = zwei" eine Wertzuweisung, gilt letzteres, werden aber Pointer, nicht Werte zugewiesen: eins zeigt nach der Zuweisung auf dasselbe Objekt wie zwei.

    Folglich ist nach der "geeigneten Änderung" der Wert von eins und zwei verschieden, falls T ein eingebauter Datentyp ist, bei selbstdefinierten ist er aber gleich, da beide Pointer ja auf dasselbe Objekt zeigen.

    Das nenne ich einen semantischen Kuddelmuddel.

    Stefan.



  • ich finde es eigentlich wesentlich besser in java als in C++, weil du eine strikte trennung zwischen simplen datentypen und klassen hast

    was IMHO einfach besser lesbar ist und du weisst was du tust

    ausserdem kannst du ja auch kein objekt einer variablen zuweisen
    also was will ich a = b machen ?

    was voellig anders waere es wenn sie die einfachen datentypen auch als klassen definiert haetten - was besser waere im sinne der OOP

    dadurch mixt man auch weniger oo ansichten mit prozeduraler programmierung

    ich hoffe ihr wisst was ich meine



  • gomberl: C++ ist keine Sprache, die eine strikte Trennung zwischen Klassen und primitiven Typen will, noch ist es eine, die für jede Variable den Overhead einer Heap-Allokation will. Klassen ergeben sich nahtlos aus "dummen" Strukturen, indem ich Memberfunktionen hinzufüge, Zugriffsrechte vergebe, und grundlegende Vorgänge wie Konstruktion/Destruktion, Kopieren und Zuweisung anpasse. Ich baue tatsächlich neue Datentypen. Nimm z.B. eine Klasse für komplexe Zahlen. Das ist schlicht und einfach eine Erweiterung der vorhandenen Datentypen, kein Objekt im Sinne der OOP, und in C++ trivial zu bauen. In Java bastelt man sich an der Stelle per Hand eine Wertsemantik (value types) zurecht (alle Felder final, keine Modifikationsmöglichkeit ...), wie bei den Strings.
    Dafür ist in C++ die Benutzung von entity types, die in der OOP häufiger vorkommen, etwas umständlicher, die man sich selbst aus den gegebenen Mitteln schneidern muss (Kopierkonstruktor und Zuweisung private machen z.B.). Aber C++ will auch keine reine OOP-Sprache sein. Es gibt kein alleinseligmachendes Paradigma(TM), und wenn, heißt es nicht OO.



  • das oo alleine nicht gluecklich macht - da gebe ich dir vollkommen recht

    und ich habe auch nichts gegen C++ im allgemeinen
    nur zum lernen ist IMHO Java besser geeignet - zumindest bei reinen OOP anwendungen

    um auf das thema zurueckzukommen
    ich sehe eigentlich keinen nachteile das java keine zeiger hat
    den die sprache ist nicht fuer extrem high performance applikationen ausgelegt und alles ander kann ich mit referenzen und einem guten OOD machen
    dabei werde ich overhead haben, aber es wird die applikation nicht sonderlich stoeren



  • PS: bevor jetzt alle Java/C#'ler schreien: Wenn ich Java/C# nicht mögen würde, würde ich wohl kaum darin programmieren, oder?

    vielleicht wirst du ja gezwungen 😃

    ich selber seh einen Vorteil von Java-Referenzen gegenüber C++Pointern- wenn beide für OO-Zwecke eingesetzt werden- darin, daß man sich drauf verlassen kann daß das referenzierte Objekt wenn man die Referenz shared (=an verschiedene Objekte weitergibt), nie gelöscht wird, aus dem Gültigkeitbereich läuft (weil ja grundsätzlich dynmisch allokiert wird) und das das Objekt automatisch deallokiert wird, nachdem alle Referenzen gestorben sind.
    Allerdings kann man bei C++ sich diese ganzen Sachen mit Smart-Pointern ja sehr schön nachbauen..


Anmelden zum Antworten