Welche pure virtual Methoden muss man implementieren?

[virtuell Realisticer]

Artchi schrieb:

Ja, weil Volkard meiner Meinung nach rumgelabert hat, nach dem Motto "Ihr wisst eh nichts!"...

Ihm geht es bestimmt nicht darum zu zeigen, dass wir nichts koennen und er mehr
Ahnung hat.

1.) Hat er verdammt viel Ahnung und das weiss er
2.) Unterstellt er niemandem, dass er "eh nichts weiss". Er hat, imho, eine
provokative Art und Weise sich auszudruecken, was aber wohl niemandem schadet,
denn in gewisser Weise fordert dass von jemandem sich etwas mehr Gedanken ueber
etwas gesagtes zu machen.

Nehmt nicht immer alles persoenlich, niemand will euch was und ganz bestimmt
will hier niemand jemanden als 'schlechter' abtun.

Artchi schrieb:

...
Da haben wir wie die dummen rumgeraten... Und es ist mir egal wieviel Posts er inne hat. Sooo doof sind wir nun auch wieder nicht, oder?

Warum raten? Ich habe die Frage direkt erstmal in google eingetippt und mich
durch die Ergebnisse gearbeitet und nebenbei auch noch meine Buecher ueber C++
ausgepackt und nachgeschaut.

Und _nein_, wir sind nicht 'sooo' doof und das hat auch niemand hier behauptet.

Ich verstehe nicht, warum viele sich mit volkard erstmal anlegen muessen, bevor
sie etwas hinnehmen. Man kann auch auf normale Art und Weise nach dem 'Warum'
fragen, da muss man nicht gleich mit boesen Smilies etc. arbeiten, imho.

mfg
v R

PS: Und ganz nebenbei, wissen wir jetzt welche pur virtuelle Memberfunktion
implementiert werden muss, hats also doch en Lerneffekt mit sich gebracht?!

[Irgendwer]

nee, falsch ausgedrückt.
dann muss die basisklasse nen dtor haben, der aufgrufen werden muss, wenigstens um das member zu löschen. indem ich nen dtor pur virtuell deklariere wird der automatische nicht mehr gebaut, sondern es wird erwartet, daß ich einen baue (in ner anderen übersetzungseinheit). wenn ich das ncht mache, gibts nen linkerfehler, weil ich diesen pur virtuellen dtor nicht implementiert habe.

Ich habe den Compiler zwar jetzt nicht zur Hand aber wenn ich mich recht errinnere dann macht der für jede Klasse automatisch ein Dtor mit inline Linkage. Wenn du jetzt in einem Module den Dtor jetzt aber definierst markiert er ihn extra und der Linker schmeisst später alle inline Versionen raus, wenn du jetzt keine Dtor extra definiert hast dann schmeist er alle inline Versionen raus bis auf eine mit der er dann linkt.

*b+=1;

war übertrieben. das ist nicht lesbarer oder in irgend einer weise besser als

Style frage, bei solchen kleinen Zeilen sagt mein Gefühl mir, dass da ein = reingehört, und bei ++*a; läuft man auch immer Gefahr zu glauben, dass es das gleiche ist wie *a++;. Und das sind schwer zu findende Fehler (wenn man nicht darauf achtet).

[SirLant]

Irgendwer schrieb:

*b+=1;

war übertrieben. das ist nicht lesbarer oder in irgend einer weise besser als

Style frage, bei solchen kleinen Zeilen sagt mein Gefühl mir, dass da ein = reingehört, und bei ++*a; läuft man auch immer Gefahr zu glauben, dass es das gleiche ist wie *a++;. Und das sind schwer zu findende Fehler (wenn man nicht darauf achtet).

Stroustroup sagt in die c++-programmiersprache mehrfach man soll nur diese Mittel
einsetzen die man sicher beherrscht und nicht um "cool zu sein" irgendwelche
tricksereien oder sonstiges einzusetzen. Und ich würde sagen, dass dies bei diesem
Beispiel auf jeden Fall zutrifft, wer sich unsicher ist, sollte Irgendwer's Methode
verwenden und wer den Unterschied kennt, der soll Volkard's Version verwenden.

[volkard]

Irgendwer schrieb:

Style frage, bei solchen kleinen Zeilen sagt mein Gefühl mir, dass da ein = reingehört, und bei ++*a; läuft man auch immer Gefahr zu glauben, dass es das gleiche ist wie *a++;. Und das sind schwer zu findende Fehler (wenn man nicht darauf achtet).

aber der a++ kommt in freier wildbahn eigentlich nur noch bei sachen wie

for(waskomplizeiertes)
  if(...)
     tuwas(*readpos++);
//*readpos++ zusammen ist ein idiom, was soviel wie (sei readpos mal 
//ein stream) readpos.get() sagt.

vor. der feststehende begriff mit dem *bla++ wird da aber gelesen, nicht mehr überlegt, was das tut.
steht ++ alleine da, ist ja ++a oder a++ von der wirkung her gleich. man bevorzugt inzwischen ++a. und zwar ganz heftig. keiner schreibt mehr for(int i=0;i<10;i++)! 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.
das hat zur folge, daß i++ fast ausgestorben ist. nach meiner persönlichen regel eh, die besagt, daß man i++ nur benutzen sollte, wenn man mir vorher nen handschriftlichen antrag gefaxt hat (und ich habe keine faxnummer).

vor diesem hintergrund kann keine verwechslung mehr zwischen ++*a und *a++ vorkommen, denn *a++ steht gar nicht zur diskussion.
übrigens ist *a++ bei mir schon sehr unerwünscht, weil ich selber früher immer (*a)++ und *(a++) nicht auseinanderhalten konnte. das hate mir auch schon gereicht, lieber *++a als *a++ zu schreiben.

das i+=1 hinegen ist viel seltener anzutreffenm als das ++i. deswegen würde ich das i+=1 ganz ablehnen. das i=i+1 jedoch ist wieder häufig. (naja, nicht gerade mit der 1 dort, aber die struktur ist oft zu sehen).
also würde ich, wenn ++*a zu mißverständlich ist, nach *a=*a+1 ausweichen.

unwichtiges detail? für mich nicht, ich kann an so fragen stundenlang brüten. muß ja auch sein, damit ich nicht jedesmal auf neue überlegen muß, bzw. damit ich wenn was ähnliches wieder vorkommt, mit dem überlegen frühzeitig auf durchdachten grund stoße.

[volkard]

SirLant schrieb:

Stroustroup sagt in die c++-programmiersprache mehrfach man soll nur diese Mittel einsetzen die man sicher beherrscht und nicht um "cool zu sein" irgendwelche tricksereien oder sonstiges einzusetzen.

das erinnert mich an ne diskussion, wo ein paar nubes schrecklichen code propagierten, den ich neben anderen anmeckerte. deren antwort war "wer das nicht versteht, kann eben kein c++". naja, vermutlich sind sie nubes geblieben.
zur "einfachheit" meine ich, daß man so coden soll, daß auch schwächere arbeitskollegen den code gut lesen können. das heißt natürlich dringenden verzicht von dicken fünffach geschachtelten (aber eigentlich ganz einfachen) schleifen. auch mal nen kommentar setzen, wenn es gar nicht anders geht. aber ich halte auch ne untergrenze für sinnvoll, bis wohin man gehen darf. und bei *a=*a+1 ist sie imho unterschritten. das klingt wie

++i; //die variable namens i wird um eins erhöht.

das kleine einmaleins muß man verlangen können (es ist keien schande und völlig normal, wenn der kollege erstmal läner für sowas braucht, aber angewöhnen muß er sich's doch irgendwann).

[Irgendwer]

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;

[Irgendwer]

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.

[Irgendwer]

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