Das ist das Ende von C++!

Ah, ok. Dann macht das natürlich Sinn. Danke dir

ten

rüdiger schrieb:

int main() {
  char buffer[sizeof(Foo)];
  Foo *ptr = new (buffer) Foo;
}

in C würde das so aussehen:

int main() 
{
  char buffer[sizeof(struct Foo)];
  struct Foo *ptr = (struct Foo*)buffer;
}

:xmas2:

Phoemuex

ten schrieb:

rüdiger schrieb:

int main() {
  char buffer[sizeof(Foo)];
  Foo *ptr = new (buffer) Foo;
}

in C würde das so aussehen:

int main() 
{
  char buffer[sizeof(struct Foo)];
  struct Foo *ptr = (struct Foo*)buffer;
}

:xmas2:

Dabei wird dann aber kein Konstruktor aufgerufen - ok, den gibts in C ja sowieso nicht, aber das ist halt der Sinn des placement-news, oder?

Felix :xmas2:

LordJaxom

Eher so die Richtung, wenn man die Abläufe originalgetreu übertragen will

int main() 
{
  char buffer[sizeof(struct Foo)];
  struct Foo *ptr = (struct Foo*)buffer;
  init_Foo(ptr);
}

:xmas2:

Sagt mal, ist das jetzt das Ende von C++? Ich will jetzt nicht alles lesen.

Nein. Es ist vielmehr das Ende von D *duck*

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)