Das ist das Ende von C++!

Julian__

hat D jemals richtig angefangen? was willst du da beenden?

mfg,
julian

So in etwa war das auch gemeint

Simon2

quote experte schrieb:

Michael E. schrieb:

Optimizer: Wieso gehst du nicht auf den eigentlichen Inhalt von Simon2s Beitrag ein?

...Sich darüber aufzuregen, dass sich das Verhalten beim Wechsel zwischen primitiven Datentypen und allen anderen ändert, ist, als würde ich mich beschweren, dass sich das Verhalten ändert wenn ich in C++ beim Rückgabetyp ein & hinzufüge bzw. entferne....

Sorry, aber das ist eine etwas schräge Analogie (* s.u.).
Wenn ich ein template instantiiere, ändere ich die Semantik seiner Schnittstelle (also die Erwartung an ihr Verhalten) nicht (im Gegensatz dazu, wenn ich beim Returnwert eine Referenz statt einer Kopie zurückgebe - ja, ich weiß, dass C++ den Returntyp nicht zur "Signatur" zählt; IMO auch nicht ganz konsistent, aber vielleicht nicht Anders zu machen).

Worauf ich hinaus wollte: Welchen Sinn macht es, ein template zu schreiben, wenn sich die Semantik dieses templates durch den instantiierenden Typ grundlegend ändert ?

Beispiel: Wenn ich in D ein template analog Folgendem schreibe ...

template <typename T>
class A {
private:
    T d;
public:
    T getD() { return d; }
};

... und die Behandlung primitiver und Klassentypen (bzgl. Kopie vs Referenz) analog zu Java funktioniert, dann verhalten sich:

A<myString> a1;
A<string> a2;

a1.getD() = "Test";
a2.getD() = "Test";

unterschiedlich.

... und das finde ich schon (vorsichtig gesagt) "unerwartet".
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 ?

(*) Natürlich kann ich das Ganze damit verknüpfen, dass ich das template auch mit string& instantiieren kann, aber einerseits sehe ich den Einsatz von & und * als bewusste Semantikänderung durch den Nutzer (und nicht nur durch die Hintertür) und andererseits ist fraglich, ob der D-User überhaupt die Wahl hat (der Javaist hat sie halt nicht, weil "alles ein Pointer" ist). Außerdem ist die Chance relativ hoch, dass templates wie das Obige insgesamt mit "Kopiersemantik" arbeitet und Dir deswegen ziemlich schnell um die Ohren knallen, dass eine Referenz nicht kopierbar ist.

Gruß,

Simon2.

P.S.: Damit nicht wieder der falsche Eindruck der "Javahetze" entsteht: In C++ ist das auch nicht so günstig geregelt, weil in meinem template der RV von getD() für primitive Typen keine l-value ist und dementsprechen die Zuweisung nicht funktioniert.

nep

Gibt es in D eigentlich auch sowas wie Reflection?

ten

nep schrieb:

Gibt es in D eigentlich auch sowas wie Reflection?

nö, D läuft ja nicht inner VM
:xmas2:

nep

Hm ok... dann find ich das schon irgendwie lustig, weil eigentlich sagen die nur was ihr Ding kann (und andere Sprachen nicht)... aber was D z.B. nicht kann und andere Sprachen dafür können wird natürlich nicht aufgelistet

Zeus

Ist halt Marketing

Phoemuex

nep schrieb:

Gibt es in D eigentlich auch sowas wie Reflection?

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...

Felix :xmas2:

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.