Frage zu Arrays

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());
        }

pyhax schrieb:

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());
        }

Mir ist klar, dass es so nicht ist (siehe C++-reference). Ich meinte, ob es *theoretisch* möglich wäre, weil ja nur die Vergleichsoperatoren des zweiten Iteratoren genutzt werden.

Ramanujan

Hacker schrieb:

Heißt du nur Ramanujan, oder kennst du Srinivasa Ramanujan?

Naja, "kennen" ist so ein weiter Begriff. Ich bin recht beeindruckt, dass er Formeln aufgestellt hat, die heute immer noch keiner beweisen kann, obwohl er schon ca. 90 Jahre tot ist. Schade, dass er schon so früh gestorben ist.

Hacker schrieb:

Das geht IMO auch schöner:
vector<T> (data, data + size);

Jo, so hab ich es jetzt auch in meinem Code stehen.