neuer Lehrer, neues Schuljahr, neues "C++"

[C++Poser]

unskilled schrieb:

<a href= schrieb:

c++ std::accumulate">
8.090.000 für c++ std::accumulate

PS: 4.060.000 für c++ std::vector

was sagt das über den gebrauch aus?

Such mal richtig
http://www.google.de/search?hl=de&q=c%2B%2B+"std%3A%3Avector"&btnG=Suche&meta=
http://www.google.de/search?hl=de&q=c%2B%2B+"std%3A%3Aaccumulate"&btnG=Suche&meta=

[unskilled]

Aho schrieb:

volkard schrieb:

Wenn mir einer sowas abliefert,

int summe=0;

int zahl;
while(cin>>zahl)
   summe+=zahl;

cout<<summe;

wäre ich nicht wirklich sauer.

Mein eigentlicher Hintergedanke war der, dass es nicht unnötig Rechenleistung verschwenden soll.
Bei einem größeren Programm ist das glaub ich vorteilhaft, wenn man Umwege und der gleichen vermeidet. So stell ich mir das vor... kann natürlich auch komplett falsch sein.

Grüße,
Martin

ich kann mir gerade nicht wirklich vorstellen, dass der einzeiler langsamer ist - außerdem fällt das wohl eh unter vorzeitige optimierung...

[volkard]

unskilled schrieb:

ich kann mir gerade nicht wirklich vorstellen, dass der einzeiler langsamer ist

Bei sowas gehe ich davon aus, daß es exakt gleich schnell is.

[unskilled]

volkard schrieb:

unskilled schrieb:

ich kann mir gerade nicht wirklich vorstellen, dass der einzeiler langsamer ist

Bei sowas gehe ich davon aus, daß es exakt gleich schnell is.

wollte ich damit sagen ;P

[tntnet]

Dravere schrieb:

volkard schrieb:

Wenn mir einer sowas abliefert,

int summe=0;

int zahl;
while(cin>>zahl)
   summe+=zahl;

cout<<summe;

wäre ich nicht wirklich sauer.

Hmmm, doch. Bitte geschweifte Klammern bei der While-Schleife!

Da geht es doch schon los. C++ verlangt keine geschweiften Klammern. Und ich verzichte häufig in solchen Situation auf diese. Die Schleife ist so wie sie ist effizient und gut lesbar. Es spricht also nichts dagegen, es so zu schreiben.

Die std::accumulate-Funktion ist in erster Linie für Templateprogrammierung sinnvoll. In so einer Situation, wie hier gezeigt, finde ich es eher einfach akademisch interessant.

Im übrigen kann man (und sollte) nach accumulate den Zustand von std::cin abfragen. Dann kann man erfahren, ob man bei eof angekommen ist oder die letzte Konvertierung auf ein nicht nummerischen Wert gestossen ist. Einfach std::cin.eof() abfragen. Ist das false, ist man nicht am Ende und die letzte Konvertierung ist offensichtlich schief gelaufen:

#include <iostream>  //std::cin / std::cout / std::endl
#include <iterator>  //std::istream_iterator
#include <numeric>   //std::accumulate

int main()
{
    std::cout << std::accumulate(std::istream_iterator<int> (std::cin), std::istream_iterator<int>(), 0) << std::endl;
    if (!std::cin.eof())
         std::cerr << "ups - schief gelaufen" << std::endl;
}

Und gleich nochmal was ohne gescheifte Klammern .

[pumuckl]

Mal abgesehen von den diversen bereits genannten Probleme bzgl. Eingabefehlern etc. finde ich den Einzeiler nicht so unheimlich schlimm. Allerdings geben ich den Kritikern recht, die die Lesbarkeit nicht so umwerfend finden. Ein oder zwei wohlplazierte Zeilenumbrüche können da Wunder wirken:

#include <iostream>  //std::cin / std::cout / std::endl
#include <iterator>  //std::istream_iterator
#include <numeric>   //std::accumulate

int main()
{
    std::cout << std::accumulate(std::istream_iterator<int>(std::cin),
                                 std::istream_iterator<int>(), 
                                 0) 
              << std::endl;
}

Machts in meinen Augen genügendlesbar - ws natürlich auch wieder Geschmackssache ist...

[Mitleid]

pumuckl schrieb:

Machts in meinen Augen genügendlesbar - ws natürlich auch wieder Geschmackssache ist...

Wo ist denn da der Unterschied?

Wenn man diese Zeilenübrüche macht, dann nur um ausreichend zu kommentieren.

#include <iostream>  //std::cin / std::cout / std::endl
#include <iterator>  //std::istream_iterator
#include <numeric>   //std::accumulate

int main()
{
    std::cout << std::accumulate(std::istream_iterator<int>(std::cin),  // wichtiger Kommentar
                                 std::istream_iterator<int>(),          // wichtiger Kommentar
                                 0)                                     // wichtiger Kommentar
              << std::endl;
}

Besonders der zweite Parameter (Off-the-end iterator) bedarf meiner Ansicht nach eines Kommentars, da er nicht unbedingt selbstsprechend ist, wenn man es so noch nicht gesehen hat.

[Shade Of Mine]

Mitleid schrieb:

Besonders der zweite Parameter (Off-the-end iterator) bedarf meiner Ansicht nach eines Kommentars, da er nicht unbedingt selbstsprechend ist, wenn man es so noch nicht gesehen hat.

Ne, doku lesen.

Man kommentiert keine standard funktionen, das ist ja wahnsinn...

[Mitleid]

Shade Of Mine schrieb:

Man kommentiert keine standard funktionen, das ist ja wahnsinn...

Welchem Pamphlet ist das nun wieder entsprungen?

Wenn es nicht intuitiv ist schreibt man den Kommentar dazu, auch wenn es irgendwo in der Doku stehen würde.

[camper]

Mitleid schrieb:

Wenn es nicht intuitiv ist schreibt man den Kommentar dazu, auch wenn es irgendwo in der Doku stehen würde.

Und wer hat das verbrochen und bestimmt, was intuitiv ist?

[Shade Of Mine]

Mitleid schrieb:

Wenn es nicht intuitiv ist schreibt man den Kommentar dazu, auch wenn es irgendwo in der Doku stehen würde.

Du man muss also ein
++i;
kommentieren.

verstehe.

PS:
wenn du das accumulate nicht verstehst, dann klicke drauf und drück F1 - da hast du eine ideale doku. viel besser als alles was man im code schreiben kann.

[Mitleid]

camper schrieb:

Und wer hat das verbrochen und bestimmt, was intuitiv ist?

Ich denke es ist klar, dass man das so nicht bestimmen kann, auch wenn ich mir durch "Massentests" die Extraktion bestimmter Vorgehensweisen vorstellen könnte.

Wenn ich jedoch meine Quelltexte "hinterlasse" versuche schon die nicht intuitiven Punkte ausreichend zu kommentieren. Maßstab ist schlicht meine Meinung. Von einer Regel, dass man Standardfunktionen nicht auch mit einem Kommentar versehen könnte/sollte hab ich noch nie gehört.

//intuitiv
vector<int> v;
accumulate(v.begin(), v.end(), 0);

// nicht intuitiv, würde ich kommentieren
accumulate(istream_iterator<int> (cin), istream_iterator<int>(), 0); 

// hier hingegen könnte ich (schweren Herzens) auf einen Kommentar verzichten 
istream_iterator<int> input_iterator(cin);
istream_iterator<int> eof;
accumulate(input_iterator, eof, 0);

Shade Of Mine schrieb:

wenn du das accumulate nicht verstehst, dann klicke drauf und drück F1 - da hast du eine ideale doku. viel besser als alles was man im code schreiben kann.

accumulate ist nicht das Problem. Nebenbei geht es auch nicht um verstehen/nicht verstehen sondern um ZÜGIG verstehen/nicht verstehen. Da sind Kommentare immer hilfreich. Natürlich kann man auch übertreiben, aber ich wüsste nicht warum hier ein kurzer Hinweis der den Begriff "Off-the-end iterator" enthält hinderlich bzw. Wahnsinn sein sollte.

Wenn du ehrlich bist freust du dich auch, wenn in Quelltexten die dir unbekannte Bibliotheken verwenden ein paar Hinweise stehen, damit du das einigermaßen flüssig lesen kannst. Komm schon. Gib es zu ...

[asc]

Mitleid schrieb:

Von einer Regel, dass man Standardfunktionen nicht auch mit einem Kommentar versehen könnte/sollte hab ich noch nie gehört.

Dennoch ist eine solche Regel durchaus bei der ein oder anderen Firma üblich - und zwar aus guten Grund. Kommentare helfen dabei Code zu verstehen - der inflationäre Einsatz wirkt aber Kontraproduktiv. Zudem sind Iteratoren eines der Grundprinzipien der STL, und wer zumindest grundlegende Ahnung von den STL-Algorithmen hat, braucht in dem erwähnten Fall auch keine Hilfe, oder weiß im schlimmsten Fall "F1" (oder ähnliches) zu verwenden.

Mitleid schrieb:

Wenn du ehrlich bist freust du dich auch, wenn in Quelltexten die dir unbekannte Bibliotheken verwenden ein paar Hinweise stehen, damit du das einigermaßen flüssig lesen kannst. Komm schon. Gib es zu ...

Hier liegt aber eine relativ bekannte Bibliothek vor. Wobei ich persönlich das fehlende std:: vor dem Algorithmus vermisse, was für mich persönlich eine viel wichtige Information ist.

[Mitleid]

asc schrieb:

Dennoch ist eine solche Regel durchaus bei der ein oder anderen Firma üblich - und zwar aus guten Grund.

Nenn mir eine. Die schreibe ich heute noch an und frage nach einer "guten" Begründung.

asc schrieb:

der inflationäre Einsatz wirkt aber Kontraproduktiv.

Ein kurzer Kommentar am Ende der Zeile ist nicht übertrieben.

asc schrieb:

... und wer zumindest grundlegende Ahnung von den STL-Algorithmen hat, braucht in dem erwähnten Fall auch keine Hilfe ...

Na ja, Hilfe braucht sowieso keiner, wenn er genug Zeit hat. Falls einer das kennt und auch selbst häufig einsetzt braucht er keine Hilfe, das ist doch klar. Falls aber nicht, kann ein Kommentar, oder eine geschickte Wahl des Variablennamens ihm in Sekunden klarmachen was da vor sich geht. Ohne F1 oder sonstigen Schnickschnack. Während dieses temporäre Objekt, tja, das steht halt da und sagt nichts.

asc schrieb:

Wobei ich persönlich das fehlende std:: vor dem Algorithmus vermisse, was für mich persönlich eine viel wichtige Information ist.

Das hab ich weggelassen, in den ersten Beiträgen ist es drin.

[hustbaer]

Was intuitiv ist, hängt logischerweise davon ab, was man selbst verwendet, und was man kennt.
Jemand der std::istream_iterator nicht kennt, wird ein Konstrukt welches std::istream_iterator verwendet vermutlich nicht intuitiv finden (SO eindeutig ist der Name ja nicht). Jemand der es selbst schon öfter verwendet hat dagegen schon.

Andrerseits halte ich es auch nicht für gut, alles zu kommentieren, was irgendjemand, der in der selben Firma bzw. am selbem Projekt arbeitet, nicht kennen könnte. Dann müsste man fast jede Zeile kommentieren.

Gerade Kenntnisse der Standard-Library sollte man finde ich voraussetzen können. Nicht in dem Sinn dass jeder schon die ganze SCL auswendig kennen muss, aber in dem Sinn, dass er/sie es sich gefälligst anzusehen hat, wenn er/sie es noch nicht kennt. Schadet ja nicht, sich "nebenbei" etwas weiterzubilden.

Nenn mir eine. Die schreibe ich heute noch an und frage nach einer "guten" Begründung.

Wir haben das so ähnlich in unseren Coding-Guidelines stehen.
Was offensichtlich ist, sollte nicht kommentiert werden. Grund: es erzeugt "noise", es bremst beim Lesem. Sprechende Variablen-, Funktions- und Klassennamen sind da wesentlich hilfreicher.
Wenn jemand zu viel (sinnlose) Kommentare schreibt, wird es aber maximal eine freundlich vorgetragene Bitte geben, dass er es in Zukunft anders machen soll. (Meist sind die Leute die viel Kommentare schreiben auch die, die schlechte Namen verwenden - von daher heisst es dann meistens "verwende bitte bessere Namen, dann musst du auch nicht so viel Kommentare schreiben").
Grund für Stunk oder auch nur ein "ernstes Gespräch" war sowas bei uns noch nie. Und es wird auch nicht systematisch überprüft.

[asc]

Mitleid schrieb:

asc schrieb:

Dennoch ist eine solche Regel durchaus bei der ein oder anderen Firma üblich - und zwar aus guten Grund.

Nenn mir eine. Die schreibe ich heute noch an und frage nach einer "guten" Begründung.

Ich nenn dir keine (meinen Lebenslauf breite ich in der Öffentlichkeit nicht aus), kann dir aber versichern das diese Regel in jeder meiner bisherigen ein ungeschriebenes Gesetz war [und ich erinnere mich an eine Firma wo dies sogar in den Programmierrichtlinien stand - die einzige in der ich tatsächlich eine solche vorliegen hatte]. Und es scheint sogar in einigen Institutionen im Öffentlichen Dienst so zu gelten, zumindest kann ich dies aus Kommentaren meines Vaters ableiten - als ich noch ausschließlich privat entwickelt hatte.

Ich finde das Kommentieren von Algorithmen und Bestandteile zu den verwendeten Standardbibliotheken (unabhängig von der Sprache) grundsätzlich nur dann sinnvoll sind, wenn sie eine wirkliche Ausnahme darstellen (was hier nicht der Fall ist). Und wenn in einem Projekt die Standardbibliothek intensiv eingesetzt wird, muss sich eh jeder zumindest die Grundlagen beibringen.

Zudem sollten Funktionen eh möglichst kurz sein um den Code gut überschauen zu können.

Mitleid schrieb:

asc schrieb:

der inflationäre Einsatz wirkt aber Kontraproduktiv.

Ein kurzer Kommentar am Ende der Zeile ist nicht übertrieben.

Doch ist sie. Und da spreche ich nicht nur auch aus eigener Erfahrung. Wenn zu viele Kommentare im Code stehen (und dies wird bei dir der Fall sein wenn du bereits hier kommentierst) überliest man sie. Das Menschliche Gehirn nimmt Ausnahmen besser wahr, als den Regelfall.

Mitleid schrieb:

asc schrieb:

... und wer zumindest grundlegende Ahnung von den STL-Algorithmen hat, braucht in dem erwähnten Fall auch keine Hilfe ...

Na ja, Hilfe braucht sowieso keiner, wenn er genug Zeit hat.

Die Aussage ist schlicht und ergreifend Schwachsinn. Wer keine Hilfe braucht, hat vermutlich nur Angst sich die Blöße zu geben. Sieht man doch auch an Schülern, Auszubildenden oder Studenten => Es kommen keine Fragen, weil man nicht Zeigen will das man es nicht versteht - auf direktes Fragen hin wird man aber Kleinlaut.

Mitleid schrieb:

Falls einer das kennt und auch selbst häufig einsetzt braucht er keine Hilfe,...

Was man genau in Projekten von Firmen erwarten kann (oder noch extremer: muss). Es ist nicht verkehrt komplexe Abläufe zu beschreiben - aber bitte keine Fälle die im Kontext einfach sind. Ja, ein Schüler kann dies kommentieren, aber nein, in Firmencode stellt dies eher ein Armutszeugnis dar.

Und das sagt jemand wie ich, der wirklich viel kommentiert (aber in 99% der Fälle nur auf Ebene der Funktion und seiner Eingabe- und Ausgabegrößen; zudem eigentlich nur im Header).

[asc]

hustbaer schrieb:

Wenn jemand zu viel (sinnlose) Kommentare schreibt, wird es aber maximal eine freundlich vorgetragene Bitte geben, dass er es in Zukunft anders machen soll.

Dies entspricht auch der Erfahrung wie es in meinen bisherigen Firmen der Fall war.

hustbaer schrieb:

(Meist sind die Leute die viel Kommentare schreiben auch die, die schlechte Namen verwenden...

...oder sie Kommentieren im Gegenzug gar nicht. So meine Erfahrung.

[Signatur]

pumuckl schrieb:

Mal abgesehen von den diversen bereits genannten Probleme bzgl. Eingabefehlern etc. finde ich den Einzeiler nicht so unheimlich schlimm. Allerdings geben ich den Kritikern recht, die die Lesbarkeit nicht so umwerfend finden. Ein oder zwei wohlplazierte Zeilenumbrüche können da Wunder wirken:

#include <iostream>  //std::cin / std::cout / std::endl
#include <iterator>  //std::istream_iterator
#include <numeric>   //std::accumulate

int main()
{
    std::cout << std::accumulate(std::istream_iterator<int>(std::cin),
                                 std::istream_iterator<int>(), 
                                 0) 
              << std::endl;
}

Machts in meinen Augen genügendlesbar - ws natürlich auch wieder Geschmackssache ist...

Clean code reads like well-written prose. - Gary Booch

Als schöne Prosa würde ich es immer noch nicht bezeichnen.

[Mitleid]

@asc
Also, ich stimme dir und hustbear in dem Punkt zu, dass offensichtliche Dinge keines Kommentars bedürfen. Aber c++ und gerade die STL sind alles andere als selbstdokumentierend. Deshalb sehe ich gerade bei STL-Konstruktionen lieber mehr Kommentare als weniger.

Wie gesagt, mir ist die Vorgabe Standardfunktionen oder Standardobjekte nicht nochmal kommentieren zu dürfen, weder in Lehrbüchern, noch in den Unternehmen begegnet. Kann mir auch nicht vorstellen, dass das Sinn macht.

Wenn du hier alles Mögliche anführst, dann lass doch den Behauptungen harte Fakten folgen (z.B. den Link auf ein Standarddokument, eine Richtlinie, ... was auch immer)

asc schrieb:

Die Aussage ist schlicht und ergreifend Schwachsinn.

Ein Quelltext ist bereits selbst eine exakte Beschreibung. Wer genug Zeit hat, kann sich auch ohne die Hilfe von Kommentaren klar machen, was mit dem Quelltext bezweckt wird. Was das mit Angst sich die Blöße zu geben zu tun hat ist mir nicht ganz klar.

P.S.: Wenn ich nochmal darüber nachdenke, brauchst du keine harten Fakten zu liefern, denn ich habe bereits jetzt das Gefühl zu viel Zeit mit der Diskussion über diese Lappalie verschwendet zu haben. Ich muss mir diese Bagatelldiskussionen mal abgewöhnen. Da könnten wir uns gleich über die bessere Lieblingsfarbe streiten. Ist genauso produktiv.

[Tyrdal]

Aber es gibt doch genug Bücher und Webseiten zur Standardbibliothek. Da reicht doch "rtfm" als Kommentar.