Welche pure virtual Methoden muss man implementieren?

das i+=1 hinegen ist viel seltener anzutreffenm als das ++i.

Dafür gibt es meines erachten nach 2 Gründe:
1.Man muss weniger tippen ; um zweimal + zu drücken braucht man die Hand nicht auf eine andere Taste zu bewegen. Bei +=1 muss man halt 3 verschiedene Tasten drücken.
2.Bei überladenen Operatoren kann ++ schneller sein als +=1 da es für die 1 optimiert werden kann was bei += nicht der Fall ist. Bei nicht optimierenden Compilern ist dies sogar der Fall für build-in types (zumindest unter x86).

keiner schreibt mehr for(int i=0;i<10;i++)!

So optimistisch wäre ich nicht.

nein, es ist jetzt for(int i=0;i!=10;++i). != und ++i, weil das auf selbstgebauten iteratoren manchmal schneller, nie lahmer und vor allem ohne jedesmal drüber nachzudenken geht. denken ist dof, deshalb macht man es auch auch bei int so.

Eigentlich Schade. Bei beinahe allen Operatoren schreibt man wer und dann was (a= a<< a|= a(...) a-> a. ...) nur ++a muss aus der Reihe tanzen. *a zähle ich nicht hinzu da ich das * nicht unter Was sondern unter wer einordne da es ja dafür sorgt, dass das Wer ein anderes Objekt ist. Aus diesem Grund hasse ich auch *a++ da hier das * nicht das Wer beeinflusst sondern das Reslutat von a++.

das i=i+1 jedoch ist wieder häufig.

Find ich aber nicht so schön wegen der Wiederholung von i.

volkard

Irgendwer schrieb:

Dafür gibt es meines erachten nach 2 Gründe...

einen hab ich auch noch: +=1 liest man als "PLUS GLEICH L", denn "PLUS GLEICH EINS" kann es ja nicht sein, weil man da ja ++ genommen hätte. und falls man ne schriftart eingestellt hat, die EIND und L gut unerscheidet, bleibt man beim lesen von +=1 trotzdem immer hängen, weil das gar nicht da stehen kann.
so geht es mir wenigstens.

Eigentlich Schade. Bei beinahe allen Operatoren schreibt man wer und dann was (a= a<< a|= a(...) a-> a. ...) nur ++a muss aus der Reihe tanzen.

jo, eigentlich schade. und ich würde auch gerne haben, daß zuweisungen immer void zurückgeben, damit keiner erst auf die idee kommt, "a^=b=a^=b" zu schreiben (was bewirkt dieser ausdruck, wenn a und b ints sind?). und nur den einen inkrementoperatr, der wie +=1 wirkt, aber als a++ geschrieben, nicht als ++a.

*a zähle ich nicht hinzu da ich das * nicht unter Was sondern unter wer einordne da es ja dafür sorgt, dass das Wer ein anderes Objekt ist.

dem nachgucken, wohin ein zeiger zeit, hätte man vielleicht besser ein schlüsselwort mit klammern verpaßt.

das i=i+1 jedoch ist wieder häufig.

Find ich aber nicht so schön wegen der Wiederholung von i.

was ist mit ner referenz?

long winData=myGetWindowLong(hwnd,GWL_USERDATA);
int *ptrB=reinterpret_cast<int*>(winData);
int& refB=*ptrB;
++b;
int a=b;

damit keiner erst auf die idee kommt, "a^=b=a^=b" zu schreiben (was bewirkt dieser ausdruck, wenn a und b ints sind?).

Der bewirkt, dass a und b ausgetauscht werden. Allgemein wird geglaubt, dass es etwas schneller ist als den Tausch mit einem dritten int aber neulich habe ich mal nachgemessen und unter P4 kann ich eigentlich gar kein Unterschied in der Geschwindikeit feststellen. Hatte sicher gestellt, dass der Compiler nicht, das eine zum anderen optimiert, für short gab es auch kein Unterschied. Der einzige Vorteil ist, dass es unter manchen Umständen kein freies Register braucht (und zwar wenn a und b bereits in einem Register sind).

dem nachgucken, wohin ein zeiger zeit, hätte man vielleicht besser ein schlüsselwort mit klammern verpaßt.

Würde wahrscheinlich einige Verwechselungen aus der Welt schaffen, wie das bei C++ Casts gegenüber C Casts ja der Fall ist.

static_cast<int>(a)+b //eindeutig
static_cast<int>(a+b) //eindeutig
(int)a+b //was den nun? (int)(a+b) oder ((int)a)+b

Anderseits * durch ein Schlüsselwort mit Klammern zu ersetzen wird manche Zeilen um ein Vielfaches verlängern, besser würde ich es finden wenn * die höchste Priorität hätte. Das würde auch bei (*a)->foo() die Klammern um *a überflüssig machen.

SideWinder

Was auch immer du mit höchster Priorität meinst, wenn du die tatsächliche höchste Priorität was Operatoren anbelangt meinst war es ein schlechter Vorschlag.

Auslösung ist immer noch mein Liebling

MfG SideWinder

SideWinder

BTW: Ob ich nun einen Dreieckstausch nehme oder diese Bitverunstaltung bringt mir vielleicht eine Nanosekunde Vorsprung, aber weitaus Aussagekräftiger ist imho der Dreieckstausch, und der Code soll ja nachher auch noch für jeden lesbar sein.

MfG SideWinder

SirLant

Naja, wenn man da den Kommentar drüber schreibt wäre es ja wieder lesbar und diese
Art von tauschen, wäre wieder etwas wo man sich fragen sollte, ob es die anderen
im Team verstehen und ob es wirklich sinnvoll ist dies zu benutzen, statt einem
Dreieckstausch.
Am besten wäre wohl ein std::swap (a, b); da weiß jeder was hier geschieht.

Ich finde es eigentlich gut, dass das dereferenzieren so kurz ist, da man sonst
unnötig komplexe und lange ausdrücke bekommt, geht natürlich etwas zu kosten der
Übersicht.

Aber wenn ich mir sowas vorstelle

#define getobject (x)  (*x)

int a = 1;
int *b = &a;

getobject (b) = 2;

da find ich den Stern doch etwas besser und vor allem bei längeren ausdrücken
müsste man das in mehrere Zeilen splitten, ok teilweise verbessert es die Übersicht
aber manchmal gehören ein paar Schritte einfach zusammen um den Sinn zu verstehen.

volkard

Irgendwer schrieb:

neulich habe ich mal nachgemessen und unter P4 kann ich eigentlich gar kein Unterschied in der Geschwindikeit feststellen. Hatte sicher gestellt, dass der Compiler nicht, das eine zum anderen optimiert, für short gab es auch kein Unterschied.

ich hab für int gemessen, und std::swap war schneller als a^=b=a^=b, wenn ich es in sortierverfahren verwendet habe.

Was auch immer du mit höchster Priorität meinst, wenn du die tatsächliche höchste Priorität was Operatoren anbelangt meinst war es ein schlechter Vorschlag

Wieso? Mit höchster Priorität meinte ich, dass zuerst Klammern ausgewerte werden, dann * und danach erst -> . ++ --