Uebungen 9.12 - 9.14

[<wWw>]

hallo,

Danke euch fuer eure Antworten und Tipps.

Shade Of Mine schrieb:

1. du hast noch immer keine Werte in den vector gepackt. Fuell den mal mit werten - kann man mit der anderen Aufgabe ja verbinden: zB werte vom user einlesen lassen.

Uh... ich habs mir extra auf einen Zettel aufgeschrieben, um es von dort aus abzutippen, aber hab es ausgelassen, danke jedenfalls

Shade Of Mine schrieb:

2. denk ueber deine suchschleife nochmal nach:
   der Kopf der Schleife ist korrekt, aber der Rest...

Du vergleichst ob beginx gleich wert ist (btw, es muss *beginx==wert heissen, da man mit * den wert anspricht auf den beginx verweist) aber was wenn *beginx nicht == wert ist? dann sagst du: nicht gefunden und beendest die funktion. Du kannst aber erst wissen ob wert in dem vector vorkommt wenn du dir alle elemente des vectors angesehen hast, sprich: wenn die schleife zuende ist.

Ja, das mit return false; bzw. ueberhaupt mit dem Beenden der Schleife war ein Fehler, den ich sehr oft mache ..
Aber eigentlich braeuchte ich auch nur eine If Anweisung ohne Else zu packen, dann wuerde das ja auch ausreichen.

Waehrend ihr meine Beispiele verbessert habt, hab ich in der Zeit weitergelernt und da sind noch solche Beispiele:

Beispiel 9.20:

Schreiben Sie ein Programm, das die Elemente eines Vektors aus Integerwerten mit den Elementen einer Liste aus Integerwerten auf Gleichheit ueberprueft.

Mein Code:

vector<int> xvec(10, 5);
list<int> xlist(10, 5);
if (xvec == xlist)
{
cout << "True" << endl;
} else {
cout << "False" << endl;
}

Uebung 9.22:

Gegeben ist vec, das 25Elemente enthaelt. Welche Auswirkung hat der Befehl vec.resize(100)? Was passiert, wenn wir als naechstes den Befehl vec.resize(10) ausfuehren wuerden?

Mein Code:

vector<int> vec(25, 3); //25 Elemente mit dem Wert(nur so als Beispiel:) 3
vec.resize(100); // Hier kommen 75Elemente mit Wert 0 dazu
vec.resize(10); // vec hat 10Elemente mit dem Wert 3

Ich hab eigentlich nur die Beispiele genommen, die ich halbwegs verstehe.
Ansonsten ist alles gut erklaert.

Mit freundlichen Gruessen - Roland

[David_pb]

vector<int> vec(25, 3); //25 Elemente mit dem Wert(nur so als Beispiel:) 3
vec.resize(100); // Hier kommen 75Elemente mit Wert 0 dazu
vec.resize(10); // vec hat immer noch 100 Elemente

[<wWw>]

David_pb schrieb:

vector<int> vec(25, 3); //25 Elemente mit dem Wert(nur so als Beispiel:) 3
vec.resize(100); // Hier kommen 75Elemente mit Wert 0 dazu
vec.resize(10); // vec hat immer noch 100 Elemente

hallo,

wieso denn das eigentlich?
mit resize mach ich ja eine neue Elementanzahl

Roland

[David_pb]

Ne, es werden keine Elemente aus dem Vektor entfernt sondern nur der end-iterator neu gesetzt. Kannst du mit vec.capacity() überprüfen.

[thordk]

klar werden die elemente entfernt. vielleicht nicht physisch, aber logisch. size liefert die anzahl der elemente im vector, nicht capacity.

[David_pb]

thordk schrieb:

klar werden die elemente entfernt. vielleicht nicht physisch, aber logisch. size liefert die anzahl der elemente im vector, nicht capacity.

Ja das ist es ja aber. Physisch sind die Elemente noch da und über operator[] kannst du sogar noch reinschreiben.

[thordk]

David_pb schrieb:

thordk schrieb:

klar werden die elemente entfernt. vielleicht nicht physisch, aber logisch. size liefert die anzahl der elemente im vector, nicht capacity.

Ja das ist es ja aber. Physisch sind die Elemente noch da und über operator[] kannst du sogar noch reinschreiben.

weil [] keinerlei kontrolle unternimmt, ob du auf gültigen speicherbereich zugreifst oder nicht. greif mal mit vector#at(int) drauf zu.

[Gast]

David_pb schrieb:

Physisch sind die Elemente noch da und über operator[] kannst du sogar noch reinschreiben.

?

Ich würde mal sagen nach einem resize(size) auf ne kleinere Größe werden alle Elemente nach size gelöscht. Der Speicher für diese Elemente ist natürlich noch da.

[David_pb]

thordk schrieb:

David_pb schrieb:

thordk schrieb:

klar werden die elemente entfernt. vielleicht nicht physisch, aber logisch. size liefert die anzahl der elemente im vector, nicht capacity.

Ja das ist es ja aber. Physisch sind die Elemente noch da und über operator[] kannst du sogar noch reinschreiben.

weil [] keinerlei kontrolle unternimmt, ob du auf gültigen speicherbereich zugreifst oder nicht. greif mal mit vector#at(int) drauf zu.

Genau so ist das. Aber da der Speicher noch vorhanden ist, ist es auch nicht "illegal" über auf Elemente über begin()+size() zu schreiben. Die Elemente sind ja noch vorhanden!
Wenn du die Größe des vectors genau anpassen willst kannst du das wie folgt machen:

std::vector< int >( vec ).swap( vec );

Dann hast du ganz genau so viel Elemente wie size() zurückgibt.

[LordJaxom]

Ich würde sagen ein Zugriff auf einen Index ausserhalb 0 <= x < size() ist schlichtweg undefiniert. Da ist vollkommen egal was capacity() aussagt.

[thordk]

es ist auch nicht "illegal" sowas zu machen:

int *p;
*p = 23;

in 9 von 10 fällen geht sowas sogar gut, weil der pointer zufällig auf irgendnen bereich verweist, auf den keine ocke anspruch erhebt. aber beim 10. mal krachts.

wenn ich nen vector resize und dann auf bereiche zugreife, die "hinter" dem letzten element liege, dann hat das dieselben auswirken. es mag in 9 von 10 fällen gut gehen, aber im 10. fall hat sich deine vector implementierung dafür entschieden, genau in den bereich seine capacity zu schreiben und wo ursprünglich eine 12 stand, bretzelst du ihm ne 723.399 hin.. ups.

[David_pb]

thordk schrieb:

wenn ich nen vector resize und dann auf bereiche zugreife, die "hinter" dem letzten element liege, dann hat das dieselben auswirken. es mag in 9 von 10 fällen gut gehen, aber im 10. fall hat sich deine vector implementierung dafür entschieden, genau in den bereich seine capacity zu schreiben und wo ursprünglich eine 12 stand, bretzelst du ihm ne 723.399 hin.. ups.

Sicher?

Standard schrieb:

-4- Complexity: The destructor of T is called the number of times equal to the number of the elements erased, but the assignment operator of T is called the number of times equal to the number of elements in the vector after the erased elements.

Ich seh hier nirgends etwas das der Speicher freigegeben werden muss. Darum sollte es zu 100% sicher sein über begin()+size() zu schreiben. Man schreibt ja nicht über den reservierten Speicherbereich hinaus.

[otze]

David_pb schrieb:

Ich seh hier nirgends etwas das der Speicher freigegeben werden muss. Darum sollte es zu 100% sicher sein über begin()+size() zu schreiben. Man schreibt ja nicht über den reservierten Speicherbereich hinaus.

da steht auch nicht, dass er es nicht muss.

[thordk]

was der standard (bzw. die spezifikation) nicht ausdrücklich definiert, ist undefiniert. solange im standard weder steht, dass der speicher ausdrücklich freigegeben werden muss oder ausdrücklich reserviert bleiben muss, ist es einer implementierung frei überlassen, wie sie das umsetzt. die meisten werden bei so einer lockeren definition darauf verzichten, den speicher explizit freizugeben, aber eine andere macht es womöglich nicht.

[David_pb]

Klar, aber eine Freigabe würde die Kompexität der Funktion verändern. Und die scheint ja vorgegeben zu sein. Naja, ein guter Gedanke sowas zu tun ist es trotzdem nicht.

[thordk]

David_pb schrieb:

Klar, aber eine Freigabe würde die Kompexität der Funktion verändern. Und die scheint ja vorgegeben zu sein. Naja, ein guter Gedanke sowas zu tun ist es trotzdem nicht.

es ist ein gedanke, den man gar nicht erst fassen sollte, weil er schlicht zu fehlerhaftem code führt.

[David_pb]

Mag sein, aber kannst du das auch belegen?

[otze]

und am ende ist noch zu beachten, dass der vector theoretisch den freien arrayplatz nutzen kann wie er lustig ist, zb zum speicherblockverschieben...

[benth_]

Wie wärs mit DevCPP ?
Der ist kostenlos...

www.bloodshed.net

[Konrad Rudolph]

Aaah, ich kann's mir nicht verkneifen …

Wieso braucht man mehr als eine Zeile, um eine Zahl in einem Vektor zu suchen?!

template <typename It>
bool contains(It begin, It end, int num)
{
    return begin != end and (*begin == num or contains(begin + 1, end, num));
}