Frage zu Arrays
-
hustbaer schrieb:
Sagen wir einfach mal es ist praktisch


-
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.
-
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.
-
Oops, mir ist gar nicht aufgefallen dass das aus dem C99 Standard und nicht dem C++ Standard ist. Hihi. War keine Absicht

-
Ist hustbaer Österreicher(Wiener?)?

-
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
).
-
Ja, genau deswegen. Krocha gabs bei uns vor geschätzt 4 Jahren zu hauf. Wobei "Dumme Proleten" es wohl wirklich besser trifft.

-
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?
-
Waaaaaaah, wo ist camper wenn man ihn braucht?

-
Passt vielleicht zum Thema: http://stackoverflow.com/questions/3426225/do-classes-with-uninitialized-pointers-have-undefined-behavior
-
Der Accountlose Benutzer hat jetzt einen Account^^
Ich werde einfach data + size benutzen. Mir war vorher nicht klar, dass man das so schreiben kann.
Ich hab noch eine andere Frage:
Wenn ich einen vector mitvector<T> (data, &data[size]);erzeuge, werden dann die Daten kopiert? Und wird beim deleten des Vectors auch das data-Array gelöscht?
-
Ramanujan schrieb:
Wenn ich einen vector mit
vector<T> (data, &data[size]);erzeuge, werden dann die Daten kopiert?
Ja.
Und wird beim deleten des Vectors auch das data-Array gelöscht?
Nein, die existieren dann völlig unabhängig voneinander.
-
Ramanujan schrieb:
Der Accountlose Benutzer hat jetzt einen Account^^
Ich werde einfach data + size benutzen. Mir war vorher nicht klar, dass man das so schreiben kann.
Ich hab noch eine andere Frage:
Wenn ich einen vector mitvector<T> (data, &data[size]);erzeuge, werden dann die Daten kopiert? Und wird beim deleten des Vectors auch das data-Array gelöscht?
Heißt du nur Ramanujan, oder kennst du Srinivasa Ramanujan?
Das geht IMO auch schöner:vector<T> (data, data + size);Dieser Konstruktor erwartet ein start-end Iteratoren-Paar. Die Werte des
zweitenersten und aller zwischen den beiden liegenden Iteratoren werden kopiert, weswegen, wie Michael Ende schon sagte, der Vector keinen Einfluss auf das eigentliche Array hat, AFAIK werden die beiden Iteratoren implizit zu const gecastet. Du kannst diesen Konstruktor wunderschön benutzen, um Container untereinander Daten austauschen zu lassen:std::vector<int> a(list.begin(), list.end());
-
Hacker schrieb:
Die Werte des zweiten und aller zwischen den beiden liegenden Iteratoren werden kopiert
Der "Wert" des zweiten Iterators wird nicht kopiert. Denn er zeigt auf das erste Element, das nicht mehr kopiert werden soll.
Michael Ende
Michael Ende ist tot.
AFAIK werden die beiden Iteratoren implizit zu const gecastet.
Warum sollte das passieren?
-
Michael E. schrieb:
Hacker schrieb:
Die Werte des zweiten und aller zwischen den beiden liegenden Iteratoren werden kopiert
Der "Wert" des zweiten Iterators wird nicht kopiert. Denn er zeigt auf das erste Element, das nicht mehr kopiert werden soll.
Flüchtigkeitsfehler, editiert

Ich dachte, die iteratoren wären const? Wenn die Werte nur kopiert werden sollen, dann kann er ja auch const sein (auch wenn ich weiß, dass es nicht so ist)?
-
Ein Iterator, der const ist, lässt sich nicht inkrementieren.
-
314159265358979 schrieb:
Ein Iterator, der const ist, lässt sich nicht inkrementieren.
Gut! Aber der zweite kann doch const sein? Die vergleichsoperatoren sind doch auch für konstante Objekte?
-
Nein, da es nur einen template-Parameter gibt.
-
@Hacker
Du hast hier gewisse Ausdrucksschwierigkeiten, auch wenn du (vermutlich) das Richtige meinst:
1. Es werden nicht die Werte der Iteratoren kopiert, sondern die Werte auf die sie zeigen.
2. Der konstante iterator den du meinst ist kein const iterator, sondern ein const_iterator. Und das ist auch der Grund warum nicht gecastet ist - der Iteratorkonstruktor ist ein Template, und da die Iteratoren eben nicht const sind, nimmt er einfach was er bekommt.
-
314159265358979 schrieb:
Nein, da es nur einen template-Parameter gibt.
Ja, aber
template <class InputIterator> vector ( InputIterator first, InputIterator const last, const Allocator& = Allocator() );@cooky: Danke, ich seh schon.