Das ist das Ende von C++!

Solange man ein keine "primitive Typen-Kopie-sonst-Referenz-Verhalten" hat, ist das unproblematisch; solange nicht generisch programmiert, ist es nur unschön.Wenn aber beides zusammenkommt, sehe ich das schon als Inkonsistenz, denn wie sollte sich der Programmierer von A oder der von myString dagegen wehren ?

Dieser Fall kann nie zustande kommen, weil man primitiven Typen nicht mit Generics verwenden kann, womit wir wieder beim Vergleich mit dem & wären ..

Gregor

Phoemuex schrieb:

Fragen wir mal anders: Was ist Reflection?

Ich hab mir mal den Artikel in der Wikipedia angesehen und irgendwie finde ich das komisch. Sowas wie das Java-Beispiel (aufrufen einer Methode eines Objekts, Name der Methode wird in einem String definiert) würde doch in C++ nicht funktionieren oder? Gibts das in C++ gar nicht und deswegen habe ich das noch nie gehört - wäre ja logisch, wenn es nur in einer VM geht, C++ läuft ja nicht in einer VM...

IMHO braucht men für Reflection keine VM. Mit C++ ist es aber i.A. trotzdem nicht machbar. Man braucht für Reflection einen gewissen Overhead in jedem Objekt, den man in C++ nicht haben möchte. Dadurch wäre der Performance-Vorsprung von C++ sofort weg.

Artchi

Naja, im Prinzip gibts schon eine Micro-Reflection in C++: RTTI. Man kann zumindest den Namen bzw. Typ eines Objektes als String erhalten. :p Letztendlich ist aber Reflection in C++ ggü. Java nicht vorhanden. Hat aber nichts mit der fehlenden VM zu tun, siehe RTTI. Manchmal kann man Reflection schon sehr nützlich einsetzen, z.B. für O/R-Mappingtools. Aber man kann nicht alles haben.

Simon2

quote experte schrieb:

...weil man primitiven Typen nicht mit Generics verwenden kann ...

Genau DIESE (unsinnig) einschränkende Regel meinte ich !
Danke, dass Du es so auf den Punkt bringst.
WENN man also im Zusammenhang mit D (oder anderen zukünftigen Sprachen) über primitive Typen/Generics redet, wäre ich eher dafür, ihre Zahl zu verringern bzw. ihre Sonderrolle aufzuheben - anstatt sie auszuweiten.

quote experte schrieb:

..., womit wir wieder beim Vergleich mit dem & wären ...

Nö - wieso ?
Mir ist schleierhaft, wie Du von "templates/primitive Typen" auf "&" kommst ...

Gruß,

Simon2.

Simon2 schrieb:

quote experte schrieb:

...weil man primitiven Typen nicht mit Generics verwenden kann ...

Genau DIESE (unsinnig) einschränkende Regel meinte ich !

Simon2 schrieb:

quote experte schrieb:

...weil man primitiven Typen nicht mit Generics verwenden kann ...

Genau DIESE (unsinnig) einschränkende Regel meinte ich !

Ich sehe schon, dass hier wieder meine "Quoting Skills" zum Zug kommen müssen.

Simon2 schrieb:

[...] Wo wird denn in meinem Beispiel bei Java (für Klassentypen) eine Kopie erzeugt ? [...]

Simon2 schrieb:

Solange man ein keine "primitive Typen-Kopie-sonst-Referenz-Verhalten" hat,

Da habe ich dich wohl falsch verstanden, immerhin dachte ich ja, dass du das "primitver-Typ-bedeutet-Kopie-des-Wertes-während-sonstige-Typen-Kopie-der-Referenz"-Verhalten meinst, wenn du - ich zitiere - "primitive Typen-Kopie-sonst-Referenz-Verhalten" schreibst. Aber das du damit in Wirklichkeit sagen wolltest, dass du es für eine unsinnige, da einschränkende, Regel hältst, dass man Generics nicht mit primitven Typen instanziieren kann, ja, darauf hätt ich natürlich auch selbst kommen können.

Deiner Meinung nach sollte man also diese Regel abschaffen und auch primitive Typen in Generics erlauben. Um die Konsistenz bei primitiven Typen zu bewahren muss natürlich nach wie vor gelten, dass diese kopiert werden, aber dass sehen wir ja nicht als Problem an, denn "primitive Typen-Kopie-sonst-Referenz-Verhalten" bei Generics bezieht sich ja nicht auf das unterschiedliche Verhalten bei der Rückgabe von primitiven und sonstigen Typen ...

Um die Ironie zu verdeutlichen: Du widersprichst dich selbst, was zeigt, dass du lediglich Interesse daran hast, Java zu kritisieren. Laut deiner Kritik kann es deinen Wünschen ja nicht gerecht werden (einerseits soll kein unterschiedliches Verhalten bei Generics durch primitive Datentypen erlaubt werden und andererseits sollen primitve Datentypen im Zusammenhang mit Generics erlaubt werden) ...

Mir ist schleierhaft, wie Du von "templates/primitive Typen" auf "&" kommst ...

Weil diese Unterstellung mit den & als Inkonsistenz genau so lächerlich ist, wie deine ..

P.S: Sorry für Doppelpost (wollte auf Vorschau klicken)

Phoemuex

quote experte schrieb:

Deiner Meinung nach sollte man also diese Regel abschaffen und auch primitive Typen in Generics erlauben. Um die Konsistenz bei primitiven Typen zu bewahren muss natürlich nach wie vor gelten, dass diese kopiert werden, aber dass sehen wir ja nicht als Problem an, denn "primitive Typen-Kopie-sonst-Referenz-Verhalten" bei Generics bezieht sich ja nicht auf das unterschiedliche Verhalten bei der Rückgabe von primitiven und sonstigen Typen ...

Um die Ironie zu verdeutlichen: Du widersprichst dich selbst, was zeigt, dass du lediglich Interesse daran hast, Java zu kritisieren. Laut deiner Kritik kann es deinen Wünschen ja nicht gerecht werden (einerseits soll kein unterschiedliches Verhalten bei Generics durch primitive Datentypen erlaubt werden und andererseits sollen primitve Datentypen im Zusammenhang mit Generics erlaubt werden) ...

Ja und? Wieso sollte das ein Widerspruch sein? Es soll ja nur kein UNTERSCHIEDLICHES Verhalten erlaubt sein. In C++ geht das doch auch, wieso sollte es also in Java nicht gehen?

Solange die nicht-primitiven Datentypen auch kopiert werden und nicht nur die Referenz, ist sowohl konsistentes Verhalten von primitiven Typen und nicht-primitiven Typen sowie das Benutzen von beiden in Generics gewährleistet. Das würde halt nur das gesamte Typensystem von Java ad-absurdum führen, das ich persönlich sowieso nicht für soooo elegant halte, aber das ist ja nur meine Meinung.

Felix :xmas2:

Generics, welche auch primitive Datentypen als Typparameter erlauben, findet man in C#. Ihr redet also über längst gegessene Eier. Dass es in Java nicht möglich ist, hat erstmal nur historische Gründe.

Solange die nicht-primitiven Datentypen auch kopiert werden und nicht nur die Referenz, ist sowohl konsistentes Verhalten von primitiven Typen und nicht-primitiven Typen sowie das Benutzen von beiden in Generics gewährleistet.

Auch ein schöner Ansatz, einziges Manko: Überschlagsmäßig 80% der Klassen erlauben keine tiefe Kopie (und das dann auch aus gutem Grund), aber hey, man muss sich eben bei Collections mit den 20% und primitiven Datentypen zufrieden geben, wenn man C++ Entwickler zufrieden stellen will ...

Generics, welche auch primitive Datentypen als Typparameter erlauben, findet man in C#. Ihr redet also über längst gegessene Eier. Dass es in Java nicht möglich ist, hat erstmal nur historische Gründe.

Wobei dieser Ansatz auch nicht gerade das gelbe vom Ei ist. Ich hab schon oft genug Fragen zu Listings wie dem Folgenden gesehen:

public struct Person {
    // ...

    public String FirstName {
        // ...
    }

    // ...
}

// ...

List<Person> list = /* ... */;
list[0].FirstName = "Foobar"; // ....

Und welcher Art waren die Fragen? Ich kann in deinem Beispiel nicht erkennen, dass ein primitiver Datentyp als Typparameter verwendet wird.

Simon2

quote experte schrieb:

...
Deiner Meinung nach sollte man also diese Regel abschaffen und auch primitive Typen in Generics erlauben. ...

Ja !

quote experte schrieb:

...
Um die Konsistenz bei primitiven Typen zu bewahren muss natürlich nach wie vor gelten, dass diese kopiert werden, ...

Nein !
Stattdessen sollte man das abschaffen. Ich denke, dass 1. nur deswegen gewählt wurde, weil man 2. haben/behalten möchte.

quote experte schrieb:

...Du widersprichst dich selbst, was zeigt, dass du lediglich Interesse daran hast, Java zu kritisieren. ...

Da Du schon das Erste nicht belegt hast, kann es auch nicht als Beleg für das Zweite herhalten.
Auch sonst bleibt Dir außer Deinen persönlichen Empfindlichkeiten kein Argument dafür, dass ich hier Javahetze betreiben würde....

Gruß,

Simon2.

Simon2

Optimizer schrieb:

Generics, welche auch primitive Datentypen als Typparameter erlauben, findet man in C#. Ihr redet also über längst gegessene Eier. Dass es in Java nicht möglich ist, hat erstmal nur historische Gründe.

Es geht hier auch nicht um C#, Java, C++, Basic, Algol oder sonstwas, sondern nur um D .... und die Aussage, dass D (angeblich)

primitive Typen und Klassen bzgl. Kopie/Referenz so behandelt wie in Java und gleichzeitig
templates unterstützt.

... sowie um meine Vermutung, dass das zu Inkonsistenzen in D führen könnte.

Gruß,

Simon2.

Optimizer schrieb:

Generics, welche auch primitive Datentypen als Typparameter erlauben, findet man in C#. Ihr redet also über längst gegessene Eier. Dass es in Java nicht möglich ist, hat erstmal nur historische Gründe.

Nee, gibts in C# auch nicht - weil es erst gar keine primitiven Typen in C# gibt.

Simon2 schrieb:

Auch sonst bleibt Dir außer Deinen persönlichen Empfindlichkeiten kein Argument dafür, dass ich hier Javahetze betreiben würde....

Wenn du behauptest, dass es besser ist eine Inkompatibilität zu bisherigen Java Anwendungen einzuführen (und die wären viel weitreichender als es Generics oder sonstiges Java 5 Features) nur damit du "int" statt "Integer" in den spitzen Klamern schreiben kannst, dann ist das Javahetze und noch dazu völlig unberechtigte.

Simon2

quote experte schrieb:

Simon2 schrieb:

Auch sonst bleibt Dir außer Deinen persönlichen Empfindlichkeiten kein Argument dafür, dass ich hier Javahetze betreiben würde....

Wenn du behauptest, dass es besser ist eine Inkompatibilität zu bisherigen Java Anwendungen einzuführen ...

Hä ?
Wen interessiert hier denn Java ?
Ich dachte, wir sprechen von D ?

Ich warte noch auf den Basic-Fanboy, der mir Basic-Hetze vorwirft, weil ich "Inkompatibilität zu bisherigen Basic-Anwendungen forderte" ....

Ich treffe hier lediglich Aussagen dazu, worauf in meinen Augen bei einer neuen Sprache (bzgl. diesem Aspekt) besonderes Augenmerk in Sachen Konsistenz geworfen werden sollte ....

BTW: Wurde hier nicht gerade als besonderer Vorteil von D gepriesen, dass auf "Altlastenkompatibilität" verzichtet werde ?

Gruß,

Simon2.

Artchi

Also, wenn Simon2 etwas an einer anderen Sprache aussetzt, kommt das Argument "Das war schon immer so und ist gewollt... hal by-design. und du hetzt gegen X." Aber wenn jemand was gegen C++ sagt, zählt das Argument "by-Design" nicht mehr. Komisch...

Simon2 schrieb:

Optimizer schrieb:

Generics, welche auch primitive Datentypen als Typparameter erlauben, findet man in C#. Ihr redet also über längst gegessene Eier. Dass es in Java nicht möglich ist, hat erstmal nur historische Gründe.

Es geht hier auch nicht um C#, Java, C++, Basic, Algol oder sonstwas, sondern nur um D .... und die Aussage, dass D (angeblich)

primitive Typen und Klassen bzgl. Kopie/Referenz so behandelt wie in Java und gleichzeitig

templates unterstützt.

... sowie um meine Vermutung, dass das zu Inkonsistenzen in D führen könnte.

Gruß,

Simon2.

Du vermutest auch, dass es in Java Parameterübergabe per Referenz gäbe. Vielleicht solltest du nicht so viele Vermutungen anstellen, ohne dir D vorher wenigstens angesehen zu haben.

Zwergli schrieb:

Optimizer schrieb:

Generics, welche auch primitive Datentypen als Typparameter erlauben, findet man in C#. Ihr redet also über längst gegessene Eier. Dass es in Java nicht möglich ist, hat erstmal nur historische Gründe.

Nee, gibts in C# auch nicht - weil es erst gar keine primitiven Typen in C# gibt.

Naja, das ist irgendwo auch Ansichtssache. Im Framework wird ein System.Int32 und seine Konsorten als Struktur mit Methoden dargestellt, allerdings handelt es sich dabei schon um einen besonderen Typ. Er ist nicht aus anderen kleineren Typen zusammengesetzt und hat im IL-Code seine eigenen, fest eingebauten Typcode, was bei anderen value types nicht der Fall. Man möchte es natürlich schon gerne so aussehen lassen, als wäre er nichts besonderes und meistens gelingt das ja auch ganz gut.

Artchi schrieb:

Also, wenn Simon2 etwas an einer anderen Sprache aussetzt, kommt das Argument "Das war schon immer so und ist gewollt... hal by-design. und du hetzt gegen X." Aber wenn jemand was gegen C++ sagt, zählt das Argument "by-Design" nicht mehr. Komisch...

Ja, der feine Unterschied ist, wenn jemand das Design versteht und nicht toll findet, dass man das als persönliche Meinung stehen lassen kann, wohingegen woanders vielleicht Klärungsbedarf besteht. Aber keine Angst, D wird schon nicht das Ende von C++ sein. :xmas1:

Zeus

Ja besonders wenn man die Specs liest und dann mit D nachprogrammiert und der Kompiler error schmeisst, könnte DM nicht wenigstens ne aktuelle Spec bieten.