vector push_back frage
-
Guten Abend.
Vielleicht ist das eine ziemlich "dumme" Frage , doch ich möchte das einfach wissen :
Ich habe einen vector als container kreiert
vector<string> std_armor(5); // 0 helm , 1 brust , 2 hand , 3 beine , 4 füße std_armor[0] = "Lederhelm"; std_armor[1] = "Lederharnisch"; std_armor[2] = "Keine Handschuhe"; std_armor[3] = "Leinenhose"; std_armor[4] = "Lederschuhe";jetzt gibt es eine eingabe , wenn die 'i' ist dann kommt man in eine for schleife.
Ich hab die mal entfernt , damit man das besser sieht :if(i == '0'){std_armor[0].erase();char xx; cin >> xx; std_armor[0].push_back(xx);}Das geht so weit , auch wenn es jetzt hier nur einen charakter in das feld schreibt.
Ich wollte jetzt aber eig. strings verwenden , doch die funktion push_back nimmt nur char!Gibts da ne alternative zu der funktion ?
und sollte ich statt push_back nicht eher insert nehmen ?
insert sieht mir in dem fall logischer aus , weil push_back ja ein neuse element erzeugt , auchwenn es hier mit eine explizitem feld arbeitet
-
char xx; cin >> xx;zu
string xx; cin >> xx;machen. Sonst liest du ja auch immer nur das erste Zeichen ein.
-
1234567890 schrieb:
char xx; cin >> xx;zu
string xx; cin >> xx;machen. Sonst liest du ja auch immer nur das erste Zeichen ein.
Haha jaja das ist ja eben das problem !
wie ich geschrieben hatte nimmt die funktion push_back(); nur char !
Sonst wäre das ja alles kein problem
-
std_armor[0] ist ein string. Wenn du denn string ändern willst, schreibe std_armor[0] = xx;
Ansonsten hat std::string eben nur eine push_back Funktion für einen char.
-
Für die Verkettung von Strings miteinander gibt es append() oder auch +=. Wenn du den alten Wert sowieso vorher löschst, kannst du auch eine ganz normale Zuweisung verwenden.
PS: Hat es eigentlich einen Grund, keinen int für den Auswahl zu verwenden?
-
Was willst du denn jetzt machen? Einen neuen String in den Vector einfügen, oder etwas an einen String im Vector abhängen? Dein Code macht jedenfalls letzteres.
-
cin >> std_armor[0];?
-
@1234567890 danke.
@CStoll Danke ich schau mit mal den operator und die funktion an
Hat es eigentlich einen Grund, keinen int für den Auswahl zu verwenden?
Wenn du das xx meinst : man soll die string felder umbenennen.
@manni66
Einen neuen String in den Vector einfügen, oder etwas an einen String im Vector abhängen? Dein Code macht jedenfalls letzteres.
Wieso sollte ich einen neune string einfügen , wenn ich eine schon erstellten string löche und wieder was reinschreibe....Also es sollte den sinn haben einen von den 5 zu editieren , sprich löchen und neu reinschreiben
-
cin >> std_armor[0];
jo danke ist ja das gleiche wie std_armor[0]= xx; , erspart mir einen schritt
-
Danke euch allen

-
7xCore schrieb:
Wenn du das xx meinst : man soll die string felder umbenennen.
Er meint den Index. Aus dem kann man doch bestimmt auch einen int machen.
-
7xCore schrieb:
@CStoll Danke ich schau mit mal den operator und die funktion an
Hat es eigentlich einen Grund, keinen int für den Auswahl zu verwenden?
Wenn du das xx meinst : man soll die string felder umbenennen.
Nein, ich meinte das
if( i=='0' )- wenn du nicht irgendwelche Gründe hast, die aus den Fragmenten nicht erkennbar sind, nimm einen "int i" (oder "unsigned i" und verwende ihn direkt als Index für die vector-Zugriffe (d.h. anstelle von "if(i=='0') machwas mit std_armor[0]; else if(i=='1') machwas mit std_armor[1]..." kannst du einfach schreiben "machwas mit std_armor[i];").
-
Wieso das ? int kann doch nur numerische Werte enthalten , oder ich meine gerade was anderes.
-
Der Index zum Zugriff auf einen vector kann auch nur numerische Werte enthalten, also sollte das nicht das Problem sein, oder?
-
Oh ne missverständniss.Ich hab deinen vorigen post nicht gelesen.
Ich hab das nur hier mit dem if gemacht , damit man das besser sieht.
Ich hab das wie du schon gesagt mit std_armor[i]; in einer for schleife geregelt.
Das wäre ja undenkbar für jedes einzelne element ein ifeinzubauen , außerdem denke ich ist das bei sehr vielen elementen performance lastig
-
7xCore schrieb:
Ich hab das nur hier mit dem if gemacht , damit man das besser sieht.
Ich hab das wie du schon gesagt mit std_armor[i]; in einer for schleife geregelt.Mit solchen Konstruktionen verwirrst du uns nur unnötig und lenkst damit von deinem eigentlichen Problem ab.
Das wäre ja undenkbar für jedes einzelne element ein ifeinzubauen , außerdem denke ich ist das bei sehr vielen elementen performance lastig
Die Performance dürfte da noch dein kleinstes Problem sein. So eine Konstruktion ist vor allem fehleranfällig und schlecht erweiterbar.
(was das "undenkbar" angeht: ich hab' schon vergleichbare Konstruktionen im produktiven Code gesehen - ein Extrembeispiel war eine Schleife ala "for(i=0;i<40;++i){ switch(i){...} } (40 Fälle ala 15 Zeilen, die sich nur in einem Variablennamen unterschieden haben))
-
(was das "undenkbar" angeht: ich hab' schon vergleichbare Konstruktionen im produktiven Code gesehen - ein Extrembeispiel war eine Schleife ala "for(i=0;i<40;++i){ switch(i){...} } (40 Fälle ala 15 Zeilen, die sich nur in einem Variablennamen unterschieden haben))
Oh mein gott ! Wenn man so was als halbwegs guter programmierer sieht bricht man doch weinend zusammen

-
7xCore schrieb:
Oh mein gott ! Wenn man so was als halbwegs guter programmierer sieht bricht man doch weinend zusammen

Da gebe ich dir völlig recht, aber vermutlich hat sich das noch nicht überall durchgesetzt

Denjenigen, der diesen Müll verzapft hat, habe ich leider nicht mehr kennengelernt, aber für diese Konstruktionen hätte ich ihm gerne noch nachträglich den Kopf geradegerückt. So blieb mir nur, das Modul wegzuwerfen und von vorne anzufangen (war einfacher als es so umzubauen daß es den neuen Anforderungen entspricht).
-
CStoll schrieb:
(was das "undenkbar" angeht: ich hab' schon vergleichbare Konstruktionen im produktiven Code gesehen - ein Extrembeispiel war eine Schleife ala "for(i=0;i<40;++i){ switch(i){...} } (40 Fälle ala 15 Zeilen, die sich nur in einem Variablennamen unterschieden haben))
Haha, solche geniale Programmier trifft man öfters.
Und ausser WTF? fällt mir dazu inzwischen nix mehr ein.