Bin ich eigentlich der einzige, der sowas macht?

volkard

HumeSikkins schrieb:

Gibt es einen besonderen Grund, warum du bei deinem NoCopy nicht auf die EBO baust?

EBO?

Na gut, dann lass ich das eben wieder sein.
Wär halt schön gewesen, weil es sich genauso benutzen lässt wie ein Member. Aber wenn volkard sagt, es ist scheiße, dann ist es scheiße.

volkard

Optimizer schrieb:

Wär halt schön gewesen, weil es sich genauso benutzen lässt wie ein Member.

wäre gar nicht so notwendig, daß es sich genauso wie ein member benutzen läßt.
ein früherer versuch, dir <windows.h> lozuwerden, machte es fast genauso wie du. aber mit ner kleinen syntax-änderung, daß man solche members immer mit -> oder * anfassen muß.
in der debug-version waren das simple smart-pointer, in der release-version dinge, die den pointee echt enthalten (in release wurde <windows.h> deshalb inkludiert).
doof wurde das dann bei parameterübergaben und so.

HumeSikkins

volkard schrieb:

HumeSikkins schrieb:

Gibt es einen besonderen Grund, warum du bei deinem NoCopy nicht auf die EBO baust?

EBO?

Ups. Sorry, Klammern vergessen. EBO = Empty base optimization.

Was ich meinte: Warum erbst du nicht von NoCopy (wo bei NoCopy im Release-Modus dann eine komplett leere Klasse ohne Copy-Ctor und Copy-Assignment-Op wäre)?

volkard

HumeSikkins schrieb:

volkard schrieb:

HumeSikkins schrieb:

Gibt es einen besonderen Grund, warum du bei deinem NoCopy nicht auf die EBO baust?

EBO?

Ups. Sorry, Klammern vergessen. EBO = Empty base optimization.

Was ich meinte: Warum erbst du nicht von NoCopy (wo bei NoCopy im Release-Modus dann eine komplett leere Klasse ohne Copy-Ctor und Copy-Assignment-Op wäre)?

EBO ist hier ist nur ne mikrooptimierung. erbschaft ist nicht der richtige weg, NoCopy zu beschreiben. hab's lange zeit erprobt und es fühlte sich nicht ok an. wenn meine klassen schon inhaltlich viel rumerbenb, stürt dort NoCopy.

und im release-code ist NOCOPY ja eh wegdefiniert.

HumeSikkins

volkard schrieb:

und im release-code ist NOCOPY ja eh wegdefiniert.

Oh man, bin ich blind. Ich habe das typedef übersehen und mich deshalb gewundert.

Also jetzt muss ich doch mal Optimizer zustimmen. Ich mache auch so etwas, Referenzen im Konstruktor mittels "new" auf einen gültiges Objekt referenzieren zu lassen und in Destruktor wieder zu löschen.
Was spricht dagenen?

Das hier:

void foo(){
  try{
    throw 5;
  }catch(...){
    throw;
  }
}
class A{
  int*a;
public:
  A():a(*(new int)){}
  ~A(){
    foo();
    delete &a;
  }
};

In dem Fall wird a nicht deleted

KPC

Das Beispiel versteh ich nicht, wo wird da überhaupt ein A erzeugt, dessen Destruktor nicht aufgerufen wird?! Außerdem hast du einen Tippfehler es muss int &a heißen.

Bashar

Dein Beispiel ist aber unrealistisch, weil Destruktoren keine Exceptions werfen sollten.

wischmop2

Mir ging's um Pointer vs. Referenz. Abgesehen von Deinem Tippfehler wäre das selbe Problem bei der Pointervariante vorhanden. Und wie Bashar schon sagt, ein Destruktor hat keine Exceptions zu werfen.

SirLant

Ich versteh nicht ganz, wieso Optimizer's Version mit den Referenzen schlecht ist, schließlich ist das ganze doch Exceptionsicher und Exceptionneutral, schlägt new fehl, wird der Speicher freigegeben und das Objekt wird nie existieren ebenso erhält der Benutzer die Exception und kann entsprechende Maßnahmen ergreifen.

Ist es einfach schlechter Stil, oder weshalb ist das so?

wischmop2

SirLant schrieb:

Ich versteh nicht ganz, wieso Optimizer's Version mit den Referenzen schlecht ist...

Ich auch nicht, wurde leider hier auch nie richtig beantwortet. Ich find's gut und mache es selber schon lange so. Schliess dich uns doch einfach an und mach's auch so .

Shade Of Mine

wischmop2 schrieb:

SirLant schrieb:

Ich versteh nicht ganz, wieso Optimizer's Version mit den Referenzen schlecht ist...

Ich auch nicht, wurde leider hier auch nie richtig beantwortet. Ich find's gut und mache es selber schon lange so. Schliess dich uns doch einfach an und mach's auch so .

Wo sind wir hier? Beim Referenzen Vergewaltigen?

Wie kommt man auf so eine kranke Idee? Referenzen sind Referenzen und Zeiger sind Zeiger.

Der einzige grund warum man sowas machen könnte wäre, dass man schreibfaul ist. Da man sich das * immer spart.

Aber mal ehrlich -> wer schreibfaul ist, der sollte nicht programmieren.

Das Problem dass man hier hat ist doch offensichtlich:
der Code ist nicht lesbar.

wenn ic ein delete &foo; sehe, dann denke ich an einen Tippfehler oder schmeiss den Code ganz weg. Lesbarkeit ist halt wichtig - ohne ist der Code nicht wirklich wiederverwendbar.

Und was bringt euch die referenz? dass das objekt copy constructable aber nicht copyable ist? geil!

Wo ist das Problem mit Zeigern? Dass der Code lesbar ist und klar??#

ihr seid auch solche if(a-b) statt if(a!=b) schreiber, stimmts?

Shade Of Mine

Und wenn ihr damit nicht Zeiger simulieren wollt, sondern einfaches Layering - dann programmiert doch gleich in Basic.

ein new ist doch unendlich lahm. da kostet doch viel zu viel. dass wäre ja, wie wenn man nen ferarri nur im 1. gang fährt...

um die abhängigkeiten zu verringern nimmt man das pimpl Idiom - das kann man nämlich recht simpel auf 0 mehrkosten bringen. auch wenn der code dann etwas unschön wird - so bleibt er lesbarer als dieses kranke referenzen vergewaltigen...

wischmop2

Shade Of Mine schrieb:

Lesbarkeit ist halt wichtig - ohne ist der Code nicht wirklich wiederverwendbar.

Lesbarkeit und Wiederverwendbarkeit sind 2 ganz unterschiedliche Sachen, oder schaust Du Dir die Windows-Sourcen an, bevor Du die Win32-Api verwendest?
Keine Ahnung was Du willst. Du redest hier von lesbarkeit im Code. Ich weiss ja nicht wie Du es machst, aber ich halte meinen Code fehlerfrei und stehe lieber auf wiederverwendbarkeit. Dann ist es für mich viel unwichtiger den Code, den ich vor einem Jahr geschrieben habe zu lesen (beim besten Willen, da ist bei größeren Projekten eh die Dokumentation das einzig richtige, anstatt zu verstehen, was man sich dabei mal gedacht hat). Dann will ich lieber wissen, wie ich die tollen Klassen verwende. Und dann weiss ich bei einem Member-Pointer eben nicht mehr, ob ich ihn auf NULL hin überprüfen muss oder nicht - bei der Referenz weiss ich es, dass ich es nicht muss, sonst hätte ich eben keine Referenz gewählt. Somit reduziert sich der Anteil an für Dich unsebarem Code auf 2 Stellen, die beim new und beim delete. Wenn Du das unlesbar findest, wäre vielleicht für Dich eher Basic das richtige... Dem gegenüber steht aber, dass ich und andere direkt wissen, wie das Objekt zu verwenden ist. Wiederwenden heisst, den Code nicht mehr lesen. Wenn ich ihn lesen >muss<, ist er nicht besonders Wiederverwendbar.
Achso, new ist langsam, stimmt und desshalb sollte man (wenn's geht) weder Referenz, noch Pointer verwenden, sondern die Objekte direkt by-value einbauen! Hat aber nix mit Referenz vs. Pointer zu tun. Aber soll etwa new bei Pointern schneller sein? Höchst interessant!
Bleiben wir beim Thema Performance: Was erzählst Du von kopierbaren Objekten? Wenn das Objekt kopierbar sein soll, muss eh ein entsprechender Copy-Konstruktor und Zuweisungs-Operator her (bin also trotz Referenz nicht schreibfaul). Wenn ich einfach nur Daten zusammengepackt speichern will, nehme ich ein struct, damit weiss ich auch gleich nach einem Jahr wieder, dass dort nur Daten gespeichert werden, sonst wäre es halt kein struct, sondern ein class (Du siehst - wiederverwendbarkeit, genau wir bei der Referenz). Wenn ich nicht nur Daten speichere, dann verbirgt sich meinstens noch mehr hinter der Klasse, z.B. ein Registrieren bei einem anderen Objekt im Konstruktor und wieder im Destruktor ein Unregistrieren, etc. Dann führt eh kein Weg am Copyconstructor und Zuweisungsoperator vorbei. In der Regel kopiere ich allerdings meine Objekte nicht. Aber jetzt weiss ich, warum Du das brauchst, weil Du jede Verwendung von Referenzen als deren Vergewaltigung ansiehst und deshalb Deine Funktionen so aussehen

void foo(CFoo a_foo);

statt

void foo(const CFoo &a_foo);

, wegen der Performance natürlich.

Also bisher haben sich alle Argumente gegen solche Referenzen für mich in Luft aufgelöst - unlesbarkeit wegen 2 Zeilen, die ich gar nicht mal unlebar finde gegenüber einer für sich sprechenden Semantik. Performancenachteile die bei Pointern die selben sind. Probleme beim Kopieren der Objekte, wo eh ein Copyconstrutor und Zuweisungsoperator hin muss. ...

@SirLant: Mach's ruhig so, ist vom Code her 100%ig ok.

volkard

wischmop2 schrieb:

Dann ist es für mich viel unwichtiger den Code, den ich vor einem Jahr geschrieben habe zu lesen (beim besten Willen, da ist bei größeren Projekten eh die Dokumentation das einzig richtige, anstatt zu verstehen, was man sich dabei mal gedacht hat).

da haben wir wohl unterschedliche vorstellungen.

Und dann weiss ich bei einem Member-Pointer eben nicht mehr, ob ich ihn auf NULL hin überprüfen muss oder nicht

man muß memberpointer eigentlich nie auf 0 prüfen. und es gibt sogar andere ansichten über das verwendensollen von referenzen als bloß:
"man nimmt immer referenzen, wenn man garantieren kann, daß keine 0 drin ist."
sachen, die die fehlersuche wirklich vereinfachen.

bei der Referenz weiss ich es, dass ich es nicht muss, sonst hätte ich eben keine Referenz gewählt.

falsches dogma.

Somit reduziert sich der Anteil an für Dich unsebarem Code auf 2 Stellen, die beim new und beim delete.

darum gehts doch gar nicht. es geht darum, daß referenzen sich wie echte objekte anfühlen sollen, während zeiger eben nur zeiger sind. ich rate dazu, *niemals* member-referenzen zu verwenden.

Wenn ich einfach nur Daten zusammengepackt speichern will, nehme ich ein struct, damit weiss ich auch gleich nach einem Jahr wieder, dass dort nur Daten gespeichert werden, sonst wäre es halt kein struct, sondern ein class

komische regel. auch die mag ich nicht.

Also bisher haben sich alle Argumente gegen solche Referenzen für mich in Luft aufgelöst - unlesbarkeit wegen 2 Zeilen, die ich gar nicht mal unlebar finde gegenüber einer für sich sprechenden Semantik. Performancenachteile die bei Pointern die selben sind. Probleme beim Kopieren der Objekte, wo eh ein Copyconstrutor und Zuweisungsoperator hin muss. ...

weil du sie nicht kapierst. das macht aber nix. ich arbeite ja nicht mit dir zusammen.

Bashar

Shade Of Mine schrieb:

Wo sind wir hier? Beim Referenzen Vergewaltigen?

Wow, eine ewiglanges wutschnaubendes Pamphlet bar jeglicher Argumente, und am Ende kommt doch noch ein Hinweis auf Pimpl. Ich hätts ehrlich gesagt nicht mehr erwartet. Du wohl auch nicht, sonst hättest du es nicht auf den nächsten Artikel verschoben. Vielleicht solltest du nicht posten, wenn du schlechte Laune hast.

volkard

ich bitte darum, damit ich nicht den durchblick verliere, daß ich weiteren postings zwischen pimpl und rimpl unterschieden wird.

wischmop2

Warum Referenzen schlecht sind, weil sie sich wie eche Objekte "anfühlen", wenn man auch echte Objekte hätte nehmen können, es nur aus irgend welchen Gründen nicht ging, würde ich ja wirklich gerne verstehen, aber gut - ich verstehe es halt nicht. Und warum Pointer dann besser sind, wenn man echte Objekte als Member hätte nehmen können, es nur aus irgend welchen Gründen nicht ging, verstehe ich halt auch nicht. etc.
Ich denke mir einfach mal, dass es Geschmackssache ist, solange das Entwicklungsteam die selbe Terminologie verfolgt, kann man es so oder so machen. Und weil man über Geschmack nicht streiten sollte, belasse ich es hierbei.