Uebungen 9.12 - 9.14
-
<wWw> schrieb:
hallo,
Ich wuerde nur gerne wissen ob nun der vector bei
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 3der letzten Zeile auf 10Elemente mit dem Wert 3 gemacht wurde oder nicht

Ja, alle Elemente die über 10 liegen werden gelöscht.
<wWw> schrieb:
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; }Ne das geht so nicht.
Du hast folgende Möglichkeiten://1. vector<int> xvec(10, 5); list<int> xlist(10, 5); if(vector<int>(xlist.begin(),xlist.end()) == xvec) cout << "true" << endl; else cout << "false" << endl; //2. // xvec oder xlist durchlaufen und mt den Elementen von // xvec bzw xlist vergleichen, darauf achten das beide gleich groß sind ;)[/quote]
-
KasF schrieb:
<wWw> schrieb:
hallo,
Ich wuerde nur gerne wissen ob nun der vector bei
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 3der letzten Zeile auf 10Elemente mit dem Wert 3 gemacht wurde oder nicht

Ja, alle Elemente die über 10 liegen werden gelöscht.
Das stimmt nur wenn die Frage sich auf die Elemente bezieht die tatsächlich- und nicht die Elemente die theoretisch, ohne neu speicher zu reservieren, zur verfügung stehen.
-
David_pb schrieb:
Das stimmt nur wenn die Frage sich auf die Elemente bezieht die tatsächlich- und nicht die Elemente die theoretisch, ohne neu speicher zu reservieren, zur verfügung stehen.
Das will mir gerade irgendwie nicht in den Kopf gehen. Kannst du bissl erläutern :).
-
Weil beim löschen der Elemente nicht die Kapazität des vectors kleiner wird sondern lediglich die Objekte zerstört werden und der end-Iterator neu gesetzt wird. Zumindest kenn ich keine Implementation von C++ die das anders löst.

-
David_pb schrieb:
Weil beim löschen der Elemente nicht die Kapazität des vectors kleiner wird sondern lediglich die Objekte zerstört werden und der end-Iterator neu gesetzt wird. Zumindest kenn ich keine Implementation von C++ die das anders löst.

Ja das ist mir schon klar: http://c-plusplus.net/forum/viewtopic-var-p-is-1322937.html#1322937
Aber alles andere momentan nicht ... Ich mach jetzt die Kiste aus

-
CStoll schrieb:
Also wenn die STL verboten ist, sollte man das auch dazusagen (aber dann würde es auch wenig Sinn machen, mit vector zu hantieren).
Dir ist der Sinn einer Uebungsaufgabe schon klar, oder?
einfach find() aufzurufen vernichtet den Sinn find selbst schreiben zu muessen...@David_pb:
Ob Elemente physisch noch da sind oder nicht, ist total egal. Es geht darum ob sie logisch da sind. Denn Elemente die logisch nicht da sind, koennen jederzeit physisch verschwinden.Diese Diskussion ist also, verzeih den Ausdruck bitte, laecherlich.
-
Shade Of Mine schrieb:
Diese Diskussion ist also, verzeih den Ausdruck bitte, laecherlich.
Naja, wen du meinst.

-
Shade Of Mine schrieb:
CStoll schrieb:
Also wenn die STL verboten ist, sollte man das auch dazusagen (aber dann würde es auch wenig Sinn machen, mit vector zu hantieren).
Dir ist der Sinn einer Uebungsaufgabe schon klar, oder?
einfach find() aufzurufen vernichtet den Sinn find selbst schreiben zu muessen...Ja, mit den vorhandenen Mitteln von ANSI-C++ das gewünschte Ziel zu erreichen (wenn bestimmte Teile nicht explizit ausgeschlossen sind, sehe ich keinen Anlass, sie nicht zu benutzen)
Zu Aufgabe 9.20: Es gibt zwar Vergleichsoperatoren für Container - aber die funktionieren nur, wenn die beteiligten Typen identisch sind. Um einen vector<> mit einer list<> zu vergleichen, mußt du:
- eins von beiden umkopieren (siehe KasF's Code)
- beide in einer Schleife durchlaufen und elementweise vergleichen
- den Algorithmus equal() auf sie loslassen (wenn erlaubt ;))
-
wenn ich so eine aufgabe gestellt hätte, würde ich einer lösung mit find die volle punktzahl geben. einer selbstgestrickten nur dann, wenn sie auch genau das macht, was gefordert war. warum? weil die lösung mit find der grundsätzlich korrekten vorgehensweise beim programmmieren entspricht: was bietet die sprache für möglichkeiten, was gehört zum lieferumfang, wie sieht mein problem aus, bietet die sprache dafür eine lösung?
das in die köpfe der leute hineinzubekommen wäre mir wichtiger, als code-hacker heranzuzüchten, die sich jeden mist selbst zusammentippen. es gibt die standard libs nicht ohne grund.
-
Wir könnten uns vielleicht darauf einigen, dass die Aufgabe nicht gut gestellt ist (leider sind solche Aufgaben aber ja Standard). Eine bessere Formulierung wäre:
Setzen Sie sich mit verschiedenen Methoden auseinander um herauszufinden, ob ein Element in einem Vektor existiert. Welche Lösungen fallen Ihnen ein? Implementieren Sie einen eigenen Code, der das Problem löst und gehen Sie darauf ein, welche Stärken und Schwächen der Code hat. Welche Lösung würden Sie in der Praxis verwenden?
Hier fördert die Aufgabenstellung nämlich ein intelligentes Auseinandersetzen mit dem Problem: Wie löst man das Problem? Wie schreibt man Code? Was ist der Nachteil von selbstgeschriebenem Code? Und implizit: Wozu sind fertige Bibliotheken da?
Wenn ich eine solche Aufgabe beantworten sollte, würde ich als Antwort meinen rekursiven Code geben, da er einfach und elegant ist. Ich würde darauf eingehen, dass der Code fehlerhaft ist, da er mit großen Bereichen nicht klarkommt und zudem potentiell ineffizient ist. Ich würde eventuell in einem Nebensatz auf eine iterative Lösung hinweisen. Und ich würde antworten, dass die beste Lösung in der Praxis das Benutzen einer erprobten Bibliotheksfunktion ist und diese nennen sowie einen Beispielaufruf angeben.
Wenn ich eine solche Aufgabe korrigieren würde, dann würde ich eine solche Antwort erwarten und für die meisten Antworten Punkte abziehen. (Natürlich wäre nicht gefordert, eine rekursive Lösung zu geben.)