3. std::vector füllen: Ist das "legal"?

std::vector füllen: Ist das "legal"?


  • Hallo zusammen,

    bin soeben in einem Buch über folgendes Codebeispiel gestoßen:

    vector<int> v;
for (int i; cin >> i; / * no expression* / )
    v.push_back(i);

    Könnte man hier nicht einfach direkt sowas machen? Und wenn ja, hat jemand eine Idee, weshalb das nicht so vom Autor dargestellt wurde?

    vector<int> v;
for (int i; cin >> i; v.push_back(i));

    Ist übrigens ernst gemeint.

    LG
    HarteWare

    0
  • G

    Klar, ist nur die Frage wie lesbar man es gerne hätte. In dem Fall ist es wahrscheinlich okay, auch wenn mir da viele widersprechen werden. Für komplexere Sachen sollte man die for-Syntax allerdings nicht mißbrauchen. Das Problem ist, dass 90% der Programmierer nicht wissen, dass man for auch für was anderes als for(int i=0; i<n; ++i) verwenden kann. Die stellt man mit solchen Konstrukten vor die Herausforderung erstmal zu verstehen was in dieser unschuldigen Zeile abgeht. Kommt im Team nicht gut an sowas, wenn man die Leute mit kreativem Einsatz von Sprachkonstrukten ausbremst :).

    0
  • V

    Weils kein Weiterschaltungsausdruck ist und deshalb nicht an dessen Platz gehört.

    0
  • ?
     

    vector<int> v;
copy(istream_iterator<int>(cin), {}, back_inserter(v));

    ?

    0
  • E

    C++/C bietet inzwischen eine große Vielfalt an. Multikulti eben. 😃
    Einfach dran gewöhnen.

    0
  • M

    HarteWare schrieb:

    [...]Könnte man hier nicht einfach direkt sowas machen? [...]

    Ein Grundsatz: Don't be fancy.

    Der Schleifenkörper mit in der Schleifensteuerung optimiert den Code um genau 0, aber es bremst tatsächlich das Lesetempo auch erfahrener Leute, weil man im Allgemeinen etwas Anderes erwartet. Zumindest stolpert man kurz und fragt sich, warum das so ist, bis man drauf kommt, dass es eigentlich keinen Vorteil hat und der Programmierer nur "clever" sein wollte. Die Zeiten, wo man ein paar Bytes im Sourcecode einsparen musste, sind schon lange vorbei. Lesbarkeit, oder besser: schnelle Erfassbarkeit durch Verwendung von Standards ist das A und O. Clever und kreativ kann man an ganz anderer Stelle sein!

    Der Buchautor hat das zumindest richtig gemacht, indem er durch seinen Kommentar explizit ausdrückt, dass diese Schleife keine Weiterschaltung hat und diese auch nicht vergessen wurde.

    Das Problem liegt an anderer Stelle: allein die Tatsache, dass er hier einen Kommentar braucht, um etwas zu erklären, was man bei anderer Formulierung vermeiden könnte, zeigt, dass da schon was nicht stimmt: Ich bin der Meinung, dass da überhaupt keine for -Schleife hingehört, denn ein for impliziert immer eine Laufvariable oder einen Iterator, der weitergeschaltet wird. Hier wird die "Laufvariable" aber als Datenpuffer missbraucht. Das kann ein while besser, weil es genau das sagt: SOLANGE eine Eingabe kommt...

    ~edit: Kommentar zum Kommentar an sich~

    0

  • Hallo und vielen Dank für Eure zahlreichen Antworten.

    Ich bin überzeugt: KISS
    (Keep It Simple Stupid)

    Es war ja bestimmt nicht dafür vorgesehen, ich kann mir vorstellen, dass solche "hacks" tatsächlich das Ganze unleserlich machen. Vermutlich lässt sich das selbe auch für die ganzen Varianten mit copy sagen.

    LG
    HarteWare

    0
  • M

    Jo, frei nach Focus: "Immer an die Leser denken"

    Irgendwo schwirrt die Faustformel, dass Code etwa 10x mehr gelesen als geschrieben wird, und zwar auch von anderen Leuten und Jahre später.

    Stellt dir einen Maintenance-Programmierer vor, der den Code pflegt oder einen Fehler sucht. Da kommt es schon darauf an, den Sinn schnell zu erfassen. Ist wie beim Buchlesen: man liest ja auch nicht jeden einzelnen Buchstaben, sondern erfasst ganze Wörter oder sogar Satzteile als Ganzes. In sofern ist es mMn schon wichtig, die Intention des Codes so klar wie möglich auszudrücken. Ein for signalisiert ggf. schon genug, so dass der Leser den Rest vielleicht gar nicht mehr groß weiterlesen muss, bzw. Fehler sofort auffallen. Blöd, wenn es dann doch etwas anderes tut.

    Letztlich geht es immer um fehlerfreien Code (und Zeit...), und je besser man diesen lesen kann, desto geringer die Chance, etwas zu übersehen.

    0

  • minastaros schrieb:

    Ein Grundsatz: Don't be fancy.

    QFT

    Und sonst ist dem nicht hinzuzufuegen.

    0
Anmelden zum Antworten