Meine liebe Hassliste

SideWinder

knivil schrieb:

Defaultargumente.

Weil?

MfG SideWinder

Kümmelkorn

Ich mag vor allem keine unleserlichen Quellcodes, also vor allem keine oder schlechte einrückung, keine Kommentare und Variablennamen nach dem Motto "Rate-mal-was-ich-bin" (letzteres bezieht sich nicht auf i als Zählvariable).

volkard schrieb:

[*]Quatsch-Optimierungen wie >>1 statt /2, inline-asm für Sachen, die der Compiler viel besser kann, new statt vector weil evtl schneller, Schleifenvariable i als char statt int, um Bits zu sparen...

Darf man (als Anfänger, der gerade C nochmal tiefer lernen will) fragen, woran man Quatsch-Optimierungen von Nicht-Quatsch-Optimierungen unterscheidet? Gelten deine Beispiele nur für C++ oder auch für C? Warum ist z.b. char statt int bzw. >>1 schlecht? (Ich frage aus Interesse und weil ich was lernen will und nicht, weil ich klugscheißen will o.ä.)

volkard

knivil schrieb:

Defaultargumente.

+1

Kümmelkorn schrieb:

(Ich frage aus Interesse und weil ich was lernen will und nicht, weil ich klugscheißen will o.ä.)

Ja, von wegen die Tricks die kenne ich schon du willst von deiner Klugscheisserei ablenken!

Du gehörst zur Kategorie: Ober Klugscheisser

Aber auch die erkenne, ich habe bereits 40 Jahre Erfahrung im erkennen von Klugscheissern du machst mir nichts vor!

volkard

Kümmelkorn schrieb:

Darf man (als Anfänger, der gerade C nochmal tiefer lernen will) fragen, woran man Quatsch-Optimierungen von Nicht-Quatsch-Optimierungen unterscheidet?

Man kann sie eigentlich nicht erkennen, wenn man nicht selber mal den Quatsch vorher selber gemacht hatte und später herausfand, daß es Quatsch war.

Weißt Du, warum ich so schnell Fehler in fremdem Code finde? Weil ich den Fehler, den ich dann da mal wo finde, selber dutzende male gemacht hatte. Wenn ich Programmierschulungen mache und nur drei Sekunden auf den Bildschirm gucken muss, um den Fehler zu sehen und helfend eingreifen zu können, hat das nix damit zu tun, daß meine Brille besonders gut wäre (sie ist aber auch gut), und nix damit, daß ich besonders gut programmieren könnte (naja, ich halte mich für recht gut, schon), sonder damit, daß ich mich an meine Fehler erinnere.

Kümmelkorn schrieb:

Gelten deine Beispiele nur für C++ oder auch für C?

Die beiden, die Du fragst, beide, ja.

Kümmelkorn schrieb:

Warum ist z.b. char statt int

a) Der Prozessor mal Intel/AMD angenommen hat einige Register. Davon lassen sich AX, BX, CX, DX wenn ich mich recht erinnere in kleinere Register aufteilen. Sowas wie AH. Es gibt aber noch viele andere Register, die nur int-size können. Will der Compiler den char in AH oder so eins tun, steigt der Registerdruck!! Will er ihn in ein anderes tun, muss er im Prinzip immer bei jeder Rechnung noch ein &0xff zufügen.

Registerdruck:=
Oh, finde keinen gescheiten Link. http://en.wikipedia.org/wiki/Register_allocation
Naja, je mehr Register der Compiler zur Verfügung hat, desto besser kann sein Optimierungsergebnis sein. Binde ich Register für bestimmte Zwecke, nehme ich ihm Freiheuten und das bestraft sich darin, daß er nicht mehr optimal arbeiten kann.

b) Liegt die Laufvariable eh auf dem Stack. Wenn man von dem ein Byte anfordert, kriegt man mindestens vier Bytes, also int-size. Weil Speicherzugriffe auf Adressen, die durch 4 teilbar sind, deutlich schneller gehen. Die Variable, die nach dem char innerhalb der Schleife angelegt werde4n wird, wird die drei unbenutzen Bytes überspringen, um eine Schnell-Variable zu sein.

c) Liegt die Laufvariable vermutlich eh in einem Register und braucht eben ein Register. Und sonst gar nix.

d) Und wenn nicht, dann hat man trotzdem (üblicherweise) 1M Stack. Wozu 3 Bytes sparen, wenn man dabei Laufzeiteinbußen hat?

Kümmelkorn schrieb:

bzw. >>1 schlecht?

Weil es die Sache nicht ausdrückt!
Gestern oder vorgestern bei mir passierte:

map<uint32_t,size_t> primfaktoren;
    while(n%2==0){//Optimierung von hier
        ++primfaktoren[2];
        n/=2;
    }//bis hier
    for(uint32_t t=3;t*t<=n;t+=2){//damit hier +=2 geht
        while(n%t==0){
            n/=t;
            ++primfaktoren[t];
        }
    }
    if(n!=1)
        ++primfaktoren[n];

Soweit klar.
Das war eine mathematische Optimierung.
Aber

while((n&1)==0){//Optimierung von hier

verkneife ich mir, denn damit verlasse ich die mathematische Sprache und gehe runter aufs Bitgefummle. Ich WEIß, daß der optimierende Compiler genau den selben Trick auch von alleine macht. Alle kleinen Trick kann der schon.

Kümmelkorn schrieb:

(Ich frage aus Interesse und weil ich was lernen will und nicht, weil ich klugscheißen will o.ä.)

Schon klar. die Klugscheißer lernt man mit der Zeit im Forum kennen.
Vermutlich hält mich auch der eine oder andere dafür, weil nicht immer sachlich bleibe, sondern auch Sachen ausspreche, die gegen bestimmte Glaubensbekenntnisse gehen, obwohl ich deren Glaube nicht wissenschaftlich widerlegen kann.

edit: Aus gegebenem Anlass, die "Kenner d..." und neu "Erkenntnis..." kannste beruhigt als Forenpest ignorieren.

Bin ich der einzige, der keine Hassliste für fremden Code hat? Jeder der hier drin seine Hassliste auflistet, hat in seinem Code Sachen, die bei jemand anderem in ner Hassliste stehen.

Warum soll man sich über sowas aufregen?

Dobi

Einrückung, Planks usw. interessieren mich kaum. Wenn ichs nicht lesen kann, lass ich einfach eine automatische Code-Formatierung drüberlaufen.

Defaultargumente, mhh interessant. Mir ist noch nix nerviges damit untergekommen. Habt ihr ein Beispiel?

Mich nerven besonders ewiglange Funktionen, vorallem wenn da viel ohne RAII gemacht wird und man immer aufpassen muss. Generell eigentlich alles, mit dem man unnötig viel Zeit verbringen muss, nur weil irgendwer zu doof oder gar faul war. Und wenn es dann bei nem Kunden crasht, der ursprüngliche Entwickler aber schon lange nicht mehr da ist, und ich es debuggen darf ...

@TravisG: Weils manchmal Spaß macht, sich zu ägern.

Swordfish

...

volkard

TravisG schrieb:

Bin ich der einzige, der keine Hassliste für fremden Code hat?

Ja, könnte sein.

Fremden Code zu debuggen ist so unglaublich schwieriger als eigenen zu debuggen...
So unglaublich viel aufwändiger. Faktor 4, wenn der andere extrem gut ist, so gut wie Bashar, Shade oder so.
Kann aber gerne mal auf 10 oder exorbitant gehen.

TravisG schrieb:

Warum soll man sich über sowas aufregen?

Wir Programmierer regen uns doch nicht auf wegen sowas. Wir können hassen, ohne, daß der Blutdruck steigt. Sonst wären wir alle tot.

Wenn ich wiedermal als Admin was mache, dann ist es schon fast regelmäßig, daß der Kunde sehr gut vorgebildet ist, wie man mit Rechnern umgeht. Ich mache genau das, was er auch tun würde, nur gebe ich nicht nach 20 Minuten auf, sondern kämpfe mich durch, selbst wenn es 2 Stunden dauert. Wiedermal von MS und Adobe Steine in den Weg gelegt kriegt, die Hardware von der Bezugsstelle taugt nix, der im Unternehmen zwangsweise eingesetze Virenscanner ist dummkonfiguriert...
Na, und?
Die ersten Programme hinzukriegen war viel unergiebiger. Die ersten Speicherlöcher in C zu stopfen, allein sie zu erkennen!
Ich löse also sein Problem. Und er schaut mich mit großen Augen an. Gibt zu, daß er schon drei Fachleute vorher befragt hatte, die aufgegeben hatten.

Einfach dran bleiben. Und insbesondere so lange fummeln und frickeln, bis ein Geistesblitz kommt. Der kommt nicht von alleine, sundern dadurch, daß man dran bleibt und sich reinvertieft.

Am Ende habe ich nur gemacht, was der Kunde auch hätte machen können, nur ich rege mich eben nicht auf, sondern frickele mich durch. Und wenn's wieder mal eine besondere Gemeinheit gibt, die ich erkenne, dann lache ich, zeige auf den Bildschirm und lache die Gemeinlinge aus. Letztendlich sichern die Gemeinlinge, Laientreiberprogrammierer und Lügedokumentierer ja auch, daß Informatiker immer mal einen schnellen Euro machen können.

cooky451

volkard schrieb:

new statt vector weil evtl schneller

Da vector alles initialisiert, kann unique_ptr<T[]> uU durchaus schneller sein.

volkard

Swordfish schrieb:

hustbaer schrieb:

* Plenken funktion ( parameter );

Fällt
if( !foo ) { bar( 43 ); }
in das Schema?

Das ist doch hübsch.

Ich würde schreiben

if(!foo){
   bar(43);
}

also antiplenk.

Kaputt wird es bei

if (!foo) {
   bar (43);
}

Ich kann mich nicht entscheiden, wohin mit den Spaces.

if ( ! foo ) {
   bar ( 43 ) ;
}

?
Nee.

if( !foo ) {
   bar( 43 );
}

Nee.

if( !foo and !bar ) {
   bar( 43 + 5*7 - 3 + pow ( 10 , 3*2 ) );
}

Nee. Stattdessen stelle ich in der IDE die Schriftart groß, sehr groß, ungemein groß, das würdet Ihr nicht glauben. Für mich ist das der beste Weg.

volkard

cooky451 schrieb:

volkard schrieb:

new statt vector weil evtl schneller

Da vector alles Initialisiert, kann unique_ptr<T[]> uU durchaus schneller sein.

Kennst Du push_back?

Ok, der Zeiger kann schneller sein. push_back verbrät eine Inkrementierung und eine Fallunterscheidung pro Einfügung, 2 Takte?
Falls man mit den Daten dann was berechnet, ist es vollkommen Latte, was push_back kostete.

Und ich bin ein Freund davon, sich selber Container zu schreiben, die halt an das Problem noch besser angemessen sind als die Standardcontainer. Bei vector<T> zum Beispiel habe ich eine Alternativ-Implemetierung Vector<T,size_t>, die intern nicht new benutzt, sondern ein std::array. Manchmal, ganz ganz selten, bläst das ganz gut. Vorstellbar als Container, der zu eriner Schach-Stellung die möglichen Züge aufnimmt. Aber fast immer ist vector echt vollkommen ok und kein zehntel Prozent Performance-Nachteil kann befürchtet werden.

Wer zerstört im Exception-Fall die Objekte, die per placement-new in den unique_ptr<T[]> gestopft wurden?

cooky451

Du denkst da an den falschen Anwendungsfall. Manchmal will man einfach nur 100 MB Speicher am Stück haben, der dann später beschrieben wird - std::vector fährt da dann erstmal mit einem memset drüber. Aber ja, die Anwendungsfälle halten sich schon in Grenzen, ist nur etwas, das mir eingefallen ist.

volkard

cooky451 schrieb:

Du denkst da an den falschen Anwendungsfall. Manchmal will man einfach nur 100 MB Speicher am Stück haben, der dann später beschrieben wird - std::vector fährt da dann erstmal mit einem memset drüber. Aber ja, die Anwendungsfälle halten sich schon in Grenzen, ist nur etwas, das mir eingefallen ist.

Ja, dafür dann den MemoryPool. Apache macht es vor. Wobei der Hauptvorteil davon ist, daß kein Destruktor befragt wird.

Daß vector aber die 100MB vorher nullen wüprde, ist schlicht falscht.
vector<char> v(100000000) tut es. Und dann reinkopieren mit v[i++]=c;
Aber das fast immer bessere
vector<char> v; nebst v.push_back(c);
ist davon frei.

volkard

cooky451 schrieb:

Du denkst da an den falschen Anwendungsfall. Manchmal will man einfach nur 100 MB Speicher am Stück haben, der dann später beschrieben wird

Und ohne ihn zu nullen? Dann geht doch push_back perfekt. Wir konstruieren einfach hinein.
Ähm, ob ich den i++ selber führe oder der vector. Ja, Registerdruck, falls i ind c.size() immer gleich sind. Falls ungleich, ist es schon recht egal.

Oder DU willst ausnutzen, daß auf Deinem BS der allokierte Speicher schon genullt ist? Nee, so fies bist Du nicht, das weiß ich.

cooky451

Na ja, angenommen du willst 100 MB binäre Daten einfach am Stück in den Speicher schaufeln (aus einer Datei z.B.) - da ließt du doch nicht immer ein byte auf einmal und pushst das dann in der vector?

Swordfish

...

volkard

Swordfish schrieb:

volkard schrieb:

[...]

Aha. Also
if(foo()){
    bar(42)
}
.

Und noch vier- bis fünfmal [Strg]+[+] drücken bitte.

volkard

cooky451 schrieb:

Na ja, angenommen du willst 100 MB binäre Daten einfach am Stück in den Speicher schaufeln (aus einer Datei z.B.) - da ließt du doch nicht immer ein byte auf einmal und pushst das dann in der vector?

Naja, vielleicht benutzue ich dann Filemapping und fresse gar keinen Speicher weg.
Aber jo, ein "Container" für nicht konstruierten Speicher, der fehlt irgendwie.

if( x < y){
       //...
} else {
       //...
}

liest sich beschissen.