privates in libraries
-
Häufig findet man in größeren Bibliotheken Privates.
Scheinbar wird Funktionalität in eine Klasse ausgelagert, die innerhalb der von außen sichtbaren definiert wurde.
In der Implementation läuft der Zugriff dann über nen pointer auf das Private.
Ein Entwickler meinte, dass man das macht, um das Speicherlayout homogen zu halten.
Nun ist meine Frage, wozu ist das wichtig? Immerhin, macht das den code meist sehr unübersichtlich und das Speicherlayout ist vollkommen irrelevant für die Performance. Zumal man im schlimmsten Fall wohl sogar Performance verliert und den Gesamtspeicherverbrauch erhöht.
Auch ein weiterer Punkt scheint keinen Sinn zu machen. Irgendwo hatte ich gelesen, dass man damit Klassen in Libs verbirgt. Allerdings könnte man das auch dadurch lösen, indem man ganz auf diese verzichtet.Also weiß jemand, wo da der Sinn oder die große Weisheit hinter diesem Konzept besteht?
-
keine ahnung, ob ich dich verstanden hab, war doch ein bischen arg wirr... normal wird nichts versteckt, es gibt aber die möglichkeit.
imho dient es einzig dazu, sauber schnittstellen zu definieren, was privat ist, kann sich in zukünftigen versionen ändern.
-
Speicherlayout ist vollkommen irrelevant für die Performance
Bullshit.
Zugriff dann über nen pointer auf das Private
Du meinst pimpl?
Also weiß jemand, wo da der Sinn oder die große Weisheit hinter diesem Konzept besteht?
Ja, aber um Unklarheiten auszuraeumen, zeig mir doch mal ein Beispiel.
Allerdings könnte man das auch dadurch lösen, indem man ganz auf diese verzichtet.
Zugunsten von ... Spaghetticode?
-
-
dgrat__ schrieb:
Nun ist meine Frage, wozu ist das wichtig? Immerhin, macht das den code meist sehr unübersichtlich und das Speicherlayout ist vollkommen irrelevant für die Performance.
Das hat wenig mit Performanz zu tun, sondern mehr mit Rückwärtskompatibilität und Kompilierzeiten.
Wenn du das Speicherlayout von Klassen veränderst, dann kannst du dir leicht selbst ausrechnen, was mit Programmen passiert, die mit einer älteren Version deiner Bibliothek kompiliert wurden.
-
Speicherlayout ist vollkommen irrelevant für die Performance
Bullshit
Ich geh sogar soweit und sage, dass durch privates der Speicher fragmentiert und die Performance sinkt. Oder spricht etwas dafür, dass durch die Zerlegung eines Objekt in zwei mit einseitigen Zugriffen etwas gewonnen wäre? Ich mag mich auch irren, darum frage ich ja...
Beispiel:
Eigentlich ist es mir negativ bei der Implementation von Kate im KDE-Projekt aufgefallen. Ansonsten findet es sich noch in vielen Klassen von QCreator, darunter in der Implementation vom MainWindow.Scheint also doch nur eine Frage der Übersicht zu sein
-
Speicher fragmentiert und die Performance sinkt
Also ist es doch relevant fuer die Performance. Was denn nu? Entscheide dich mal!
Scheint also doch nur eine Frage der Übersicht zu sein
Nein, ist es nicht.
-
Bin mir nicht sicher. Mir fallen jedenfalls keine positiven Aspekte ein.
-
dgrat__ schrieb:
Bin mir nicht sicher. Mir fallen jedenfalls keine positiven Aspekte ein.
Wurden schon genannt.
class com_port { public: com_port(int port, int baud, int fc); ~com_port(); // setup device for reading and writing bool open(); void close(); // waits on events for a specific time in ms // returns false on timeout bool wait_for(int ms); // reads all available bytes std::vector<uint8_t> read(); // write bytes to comm port // returns number of written bytes unsigned long write(std::vector<uint8_t> const& buffer); private: class com_port_impl; std::unique_ptr<com_port_impl> pimpl; };
Angenommen ich fuege nur eine Membervariable hinzu? Alle anderen Benutzer der Klasse/Bibliothek muessen neu kompilieren, da sich das Speicherlayout veraendert hat. Tue ich das in der
com_port_impl
, juckt es niemanden. Was ist, wenn ich betriebssystemspezifische Sachen kapseln moechte? Ja, incom_port_impl
, da gibst dann eine fuer Linux oder Windows, niemanden juckts, niemand sieht haessliche defines etc.
-
das hört sich in der tat sehr positiv an. thx.