Frage zu Arrays

Michael E.

Guckst du hier (mit Beispiel): http://www.cplusplus.com/reference/stl/vector/vector/

Kann man

vector<T> (data, &data[size]);

schreiben oder kann das zu Problemen führen, da data[size] ja eigentlich nicht existiert? Aber durch & wird darauf ja gar nicht zugegriffen oder?

Michael E.

Ich denke nicht, dass du in der Praxis Probleme damit bekommst, aber erlaubt ist es eigentlich nicht, weil zuerst data[size] ausgewertet wird und erst dann die Adresse davon genommen wird. Schreib doch einfach wie im verlinkten Beispiel

vector<T> (data, data + size);

Caligulaminus

Michael E. schrieb:

...weil zuerst data[size] ausgewertet wird...

Hmmmm...

Caligulaminus' Bauch sagt: Da wird nichts ausgewertet, sondern schlicht und ergreifend eine Adresse errechnet.

Ich finde

vector<T> (data, data + size);

auch schöner.

hustbaer

@Accountloser_Benutzer & Caligulaminus

Ob auf etwas "zugegriffen" wird, oder nicht, ist vollkommen egal, da der Standard sagt, dass man keine ungültigen Adressen erzeugen oder rumreichen darf.
(Ausnahme: man kann und darf undefinierte Adressen erzeugen, indem man einen Zeiger erzeugt ohne ihn zu initialisieren. Man darf diesen Zeiger dann aber nur überschreiben, und auch nicht z.B. rumreichen oder kopieren.)

D.h. &data[size] wäre grundsätzlich problematisch.

Wäre, weil es genau für das "one past last element" von Arrays eine grosse dicke Ausnahme im Standard gibt: man darf die Adresse des "one past last element" erzeugen und auch rumreichen.
Diese Ausnahme existiert, um eine gängige Praxis zu legalisieren: das Arbeiten mit Zeigerpaaren, von denen der "end" zeiger eben genau eins hinter das letzte Element zeigt.

Dadurch ist &data[size] also doch wieder legal.

( &data[size + 1] bleibt aber dennoch falsch, ganz egal ob man nun auf das Element zugreift oder nicht. Einzige Ausnahme wäre innerhalb von sizeof()/typeid() oder ähnlichen Konstrukten, wo so-gut-wie alles erlaubt ist.)

Michael E.

hustbaer schrieb:

Dadurch ist &data[size] also doch wieder legal.

Hast du einen Beleg dafür? Ich weiß, dass man data + size genau wegen dieser Ausnahme berechnen darf, aber ich sehe noch nicht, woraus dann die Legalität von &data[size] folgt.

Meine Meinung (ohne Recherche): data[size] ist nicht definiert, weshalb ein Zeiger darauf ebenfalls nicht definiert ist.

Caligulaminus

hustbaer schrieb:

[..]der Standard sagt, dass man keine ungültigen Adressen erzeugen oder rumreichen darf.[..]
[..]grosse dicke Ausnahme[..]
[..]man darf die Adresse des "one past last element" erzeugen und auch rumreichen.[..]

Hmmm... elegant is dann aber doch anders. Naja - gewachsene Systeme halt...

Legal oder illegal, es wird nichts ausgewertet, sondern lediglich eine(pseudo-)Adresse errechnet.

Michael E.

Caligulaminus schrieb:

Legal oder illegal, es wird nichts ausgewertet, sondern lediglich eine(pseudo-)Adresse errechnet.

Wenn der Code illegal ist, sprich UB hat, kann er auch die Adresse von Barack Obama berechnen und daraufhin Shakespeare zitieren. Und das alles sogar, bevor die pöse Zeile erreicht wird.

hustbaer

@Michael E.:
Beleg hab' ich keinen dafür zur Hand.

Aber...

data[size] wird erstmal zu *(data + size) .
D.h. als erstes kommt mal der Array-to-Pointer decay von "data", und danach die Addition. Beides noch unproblematisch. Danach kommt der böse *.

Nur das Ergebnis davon ist erstmal noch ne Lvalue (vom Typ T& wenn ich nicht ganz daneben liege). In &data[size] holen wir uns dann die Adresse von dieser Lvalue.

Die Frage ist also: dürfen wir auch Lvalue-Referenzen auf "one past (the) last element" erzeugen? Ich sehe keinen Grund der dagegen spricht, also behaupte ich einfach mal: ja, dürfen wird

EDIT:
Hier auch zum gleichen Thema:
http://stackoverflow.com/questions/988158/take-the-address-of-a-one-past-the-end-array-element-via-subscript-legal-by-the
Siehe Antwort von Adam Rosenfield, Zitat aus §6.5.3.2, paragraph 3

The unary & operator yields the address of its operand. If the operand has type ‘‘type’’, the result has type ‘‘pointer to type’’. If the operand is the result of a unary * operator, neither that operator nor the & operator is evaluated and the result is as if both were omitted, except that the constraints on the operators still apply and the result is not an lvalue. Similarly, if the operand is the result of a [] operator, neither the & operator nor the unary * that is implied by the [] is evaluated and the result is as if the & operator were removed and the [] operator were changed to a + operator. Otherwise, the result is a pointer to the object or function designated by its operand.

hustbaer

Caligulaminus schrieb:

hustbaer schrieb:

[..]der Standard sagt, dass man keine ungültigen Adressen erzeugen oder rumreichen darf.[..]
[..]grosse dicke Ausnahme[..]
[..]man darf die Adresse des "one past last element" erzeugen und auch rumreichen.[..]

Hmmm... elegant is dann aber doch anders. Naja - gewachsene Systeme halt...

Sagen wir einfach mal es ist praktisch

Caligulaminus

Michael E. schrieb:

[..]kann er auch die Adresse von Barack Obama berechnen[..]

Oder die meines Nachbarn...

Meine Aussage ist: es wird nichts "ausgewertet" (i.e. dereferenziert) sondern nur die Adresse meines Nachbarn errechnet. Es findet also nichts gefährliches oder aufwendiges statt.

Caligulaminus

hustbaer schrieb:

Sagen wir einfach mal es ist praktisch

hustbaer

Caligulaminus schrieb:

Michael E. schrieb:

[..]kann er auch die Adresse von Barack Obama berechnen[..]

Oder die meines Nachbarn...

Meine Aussage ist: es wird nichts "ausgewertet" (i.e. dereferenziert) sondern nur die Adresse meines Nachbarn errechnet. Es findet also nichts gefährliches oder aufwendiges statt.

Man kann wohl schwer mit nicht-standard Vokabular argumentieren, was der Standard als UB definiert oder nicht.

Das da ist z.B. UB:

void foo()
{
    int* p = new int; // OK
    int* p2; // OK
    delete p; // OK
    p2 = p; // BAM, oida - UB!
}

Das da IMO auch:

void bar()
{
    int* p; // OK
    int* p2 = p; // BIG BADABOOM, UB!
}

Nach deiner Argumentation dürfte in beiden Fällen nix passieren.
Laut Standard ist trotzdem beides UB, da man nur Zeigerwerte auf gültige Objekte (bzw. wieder mit der "one past last" Ausnahme) rumreichen darf.

Michael E.

hustbaer schrieb:

The unary & operator yields the address of its operand. If the operand has type ‘‘type’’, the result has type ‘‘pointer to type’’. If the operand is the result of a unary * operator, neither that operator nor the & operator is evaluated and the result is as if both were omitted, except that the constraints on the operators still apply and the result is not an lvalue. Similarly, if the operand is the result of a [] operator, neither the & operator nor the unary * that is implied by the [] is evaluated and the result is as if the & operator were removed and the [] operator were changed to a + operator. Otherwise, the result is a pointer to the object or function designated by its operand.

Klingt stichhaltig für C (auch wenn ich aus dem "except that the constraints on the operators still apply" noch nicht so ganz schlau werde). Wahrscheinlich kann man davon ausgehen, dass es dann in C++ ebenso legal ist. Danke für die Recherche.

hustbaer

Oops, mir ist gar nicht aufgefallen dass das aus dem C99 Standard und nicht dem C++ Standard ist. Hihi. War keine Absicht

314159265358979

Ist hustbaer Österreicher(Wiener?)?

hustbaer

314159265358979 schrieb:

Ist hustbaer Österreicher(Wiener?)?

Österreicher ja, Wiener nein.
Wieso, wegen des "BAM, oida"? Das schreib ich nur weil ich es witzig finde, bin aber kein angehöriger der Gruppe die sich neuerdings als "Krocha" bezeichnet (früher auch als "Dumme Proleten" bekannt - k.A. wieso die nen neuen Namen erfinden mussten ).

314159265358979

Ja, genau deswegen. Krocha gabs bei uns vor geschätzt 4 Jahren zu hauf. Wobei "Dumme Proleten" es wohl wirklich besser trifft.

dot

Krocha sind doch schon wieder sowas von gestern... :p

Ich konnte in meinem Draft des C++ Standard nichts entsprechendes entdecken. Ich denk mal, wenn man's ganz sicher haben will sollte man wohl &vector[0] + size machen. Mag natürlich sein dass das im echten Standard anders steht, vermutlich aber nicht. Evtl. sollte man das reporten?

hustbaer

Waaaaaaah, wo ist camper wenn man ihn braucht?