vector push_back frage



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


Anmelden zum Antworten