Frage zu Arrays

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?

cooky451

Passt vielleicht zum Thema: http://stackoverflow.com/questions/3426225/do-classes-with-uninitialized-pointers-have-undefined-behavior

Ramanujan

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 mit

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

erzeuge, werden dann die Daten kopiert? Und wird beim deleten des Vectors auch das data-Array gelöscht?

Michael E.

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 mit
vector<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 ~~zweiten~~ ersten 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());

Michael E.

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)?

314159265358979

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?

314159265358979

Nein, da es nur einen template-Parameter gibt.

cooky451

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

Michael E.

Hacker schrieb:

Ja, aber

Ja, aber was? Der erste Iterator kann nicht konstant sein, beide Iteratoren müssen den gleichen Typ haben.

pyhax

Hacker schrieb:

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.

GCC 4.6:

/**
       *  @brief  Builds a %vector from a range.
       *  @param  first  An input iterator.
       *  @param  last  An input iterator.
       *  @param  a  An allocator.
       *
       *  Create a %vector consisting of copies of the elements from
       *  [first,last).
       *
       *  If the iterators are forward, bidirectional, or
       *  random-access, then this will call the elements' copy
       *  constructor N times (where N is distance(first,last)) and do
       *  no memory reallocation.  But if only input iterators are
       *  used, then this will do at most 2N calls to the copy
       *  constructor, and logN memory reallocations.
       */
      template<typename _InputIterator>
        vector(_InputIterator __first, _InputIterator __last,
               const allocator_type& __a = allocator_type())
        : _Base(__a)
        {
          // Check whether it's an integral type.  If so, it's not an iterator.
          typedef typename std::__is_integer<_InputIterator>::__type _Integral;
          _M_initialize_dispatch(__first, __last, _Integral());
        }