2016-10-16 7 views
2

In diesem link from the isocpp.org faq in dem gegebenen Beispiel wird ein Fred-Objekt mit der Platzierung wird neu in einem Puffer aufgebaut, die wie ich die strengen Aliasing Regeln kennen strenge Aliasing Regelverletzung

char memory[sizeof(Fred)] 

für

für ein anderes Objekt dh zugewiesen wird erlaubt uns, das Gegenteil zu tun, dh für ein Objekt von welchem ​​Typ auch immer, wir dürfen einen char* Punkt haben und wir können diesen Zeiger dereferenzieren und benutzen wie wir wollen.

Aber hier im Beispiel passiert das Gegenteil. Was vermisse ich?

+0

Was stimmt nicht mit der Frage, die mir den Downvote gab? – user183833

+2

gibt es auch Schüchterne, kümmert sich nicht um sie. Ich habe +1 gegeben. Gib nicht auf, um mit der Frage nachzufragen, wenn du feststeckst. Die Website ist zum Lernen gedacht. – snr

+0

Es würde die Frage verbessern, in der Frage den Code zu zeigen, um den Sie bitten, anstatt einen externen Link zu haben, der sich im Laufe der Zeit ändern kann, und hat mehrere Codebeispiele. –

Antwort

1

Placement-neu erstellt ein neues Objekt. Es aliasiert das alte Objekt nicht. Das alte Objekt (das Array char in diesem Beispiel) wird als nicht mehr vorhanden betrachtet, wenn das Placement-new ausgeführt wird.

Vor der Platzierung neu, gibt es Speicher gefüllt mit char Objekte. Nach der Platzierung neu, gibt es Speicher gefüllt mit einem Fred Objekt.

Da kein Aliasing vorhanden ist, gibt es keine Probleme mit striktem Aliasing.

+0

Ich glaube, die Verwendung von "Speicher" nach der Platzierung neu in diesem Beispiel ist undefiniertes Verhalten. Ist das korrekt? Was ist mit 'Ort'? – esam

+0

Ich denke, die Verwendung von Speicher danach wäre nicht undefiniert. Wegen des Snippets, den StoryTeller oben gepostet hat. Also @ M.M Ich denke, ich habe es.Eine Sache, wenn jemand nun einen Zeiger char * im Speicher hatte, außerhalb dieser Funktion und wusste, dass dort ein Objekt vom Typ Fred gespeichert ist. Er würde es zu Fred * neu interpretieren wollen. Der Grund, warum er dies tun darf, ist wegen 5 in diesem [link] (http://en.cppreference.com/w/cpp/language/reinterpret_cast). Aber dann zur Dereferenzierung würde er eine der Kugeln von Typ Aliasing von unten in dieser Verbindung brauchen, um wahr zu halten, um es zu rechtfertigen. Recht? Wenn ja welche? – user183833

+0

Oder auch in diesem Zusammenhang zählt das nicht als Aliasing? – user183833

2

Die strengen Aliasing-Regeln erwähnen nicht, dass Fred* in char* umgewandelt werden muss. Nur die Variablen vom Typ char* und Fred* können auf dasselbe Objekt zeigen und für den Zugriff verwendet werden.

[basic.lval] paragraph 8

Zitiert Wenn ein Programm versucht, den gespeicherten Wert eines Objekts durch eine glvalue anderer als einer der folgenden Typen zuzugreifen, das Verhalten ist undefined:

  • die dynamische Art des Objekts,

    [..]

  • ein char oder unsigned Char-Typ.

+0

Ja, aber das, was ich im Beispiel verstehe, ist das Gegenteil. Auf den Wert des Objekts wird vom Typ Fred zugegriffen. Was dieser Ausschnitt, den Sie angaben, sagt, ist für die andere Richtung, d. H. Ein Fred-Objekt, auf das von einem Char-Typ zugegriffen wird. – user183833

+0

Wird der "dynamische Typ" hier auch in Bezug auf Vererbung bezeichnet? – user183833

+0

@ user183833 Das Snippet erzwingt keine Richtung. Sie sind beide in diesem Zusammenhang gültig. Und ja, es ist dynamisch in Bezug auf die Vererbung. – StoryTeller