C++11 (aka C++0x) - Approval of Final Committee Draft
-
Simon2 schrieb:
1.) Wenn nicht wenigstens die Namen "reserviert" wären, könnten hässliche Namenskollisionen mit abgeleiteten Klassen auftreten (die nicht der Compiler erkennen kann).
Das Problem tritt aber auch jetzt schon auf, weil zuerst gekuckt wird worauf sich ein Identifier bezieht und dann erst wird der Zugriff geprüft. Du kannst also mit privaten Members globale ungewollt verdecken. Den privaten Teil einer Basisklasse zu verändern kann dazu führen, dass eine Abgeleitete bricht. Wenn du Namen aus der Klasse raus bewegst, dann verkleinerst du das aktuelle Problem sogar geringfügig.
-
Objective-C hat ein Feature namens category um uA das private Problem zu lösen. So wirklich toll ist das aber auch nicht. Ideal wäre es, wenn eine Klasse keine geschlossene Einheit ist, sondern man jederzeit neue Funktionen hinzufügen könnte...
Für das malloc problem kannst du einfach ein #define machen und malloc ein objekt returnen lassen dass sich implizit in alle zeiger typen konvertieren lässt. im idealfall lässt man natürlich den c code in einer .c datei, aber das geht ja leider nicht immer...
-
Shade Of Mine schrieb:
Ideal wäre es, wenn eine Klasse keine geschlossene Einheit ist, sondern man jederzeit neue Funktionen hinzufügen könnte...
So wie mit Extension Methods oder Class Helpers?
-
Shade Of Mine schrieb:
Objective-C hat ein Feature namens category um uA das private Problem zu lösen. So wirklich toll ist das aber auch nicht.
Können diese Erweiterungsfunktionen dann auch auf die Interna der Klasse zugreifen oder diese gar durch zum Beispiele neue Datenmember erweitern? Ich gehe mal davon aus, dass dies nicht möglich ist. Ich kenne mich mit Obj-C leider gar nicht aus und so aussagekräftig ist der Wikipedia Artikel leider nicht.
Shade Of Mine schrieb:
Ideal wäre es, wenn eine Klasse keine geschlossene Einheit ist, sondern man jederzeit neue Funktionen hinzufügen könnte...
Vielleicht. Mein Bauchgefühl tendiert da aber in eine andere Richtung. In C++ hast du die Möglichkeit freie Funktionen zu erstellen. Ich würde es für sinnvoller halten das Klasseninterface minimal zu halten und dann komplexere Funktionalität mit freien Funktionen aufzubauen.
-
Ben04 schrieb:
Können diese Erweiterungsfunktionen dann auch auf die Interna der Klasse zugreifen oder diese gar durch zum Beispiele neue Datenmember erweitern?
Datenmember muss ich zugeben, weiss ich nicht. Ich denke ja, würde aber meine Hand dafür nicht ins feuer legen. Eine category kann private daten haben, aber ob eine andere category dann darauf zugreifen kann - das weiss ich jetzt nicht.
zugriff auf private member hat eine category aber.
Vielleicht. Mein Bauchgefühl tendiert da aber in eine andere Richtung. In C++ hast du die Möglichkeit freie Funktionen zu erstellen. Ich würde es für sinnvoller halten das Klasseninterface minimal zu halten und dann komplexere Funktionalität mit freien Funktionen aufzubauen.
mir persönlich gefällt dieses "willkürliche" trennen zwischen member und freistehende funktion irgendwie nicht. natürlich ist die trennung nicht wirklich willkürlich, aber als anwender der klasse sind mir oft die design entscheidungen dahinter egal.
zB list::sort versus std::sort. natürlich macht es sinn dass eine list ein eigenes sort anbietet, aus einer technischen sicht, aber wenn ich das ding nur sortieren will, ist mir das eigentlich egal. wobei das jetzt von der signatur her ein dummes beispiel ist.
categories erlauben mir zB ähnlich dem prototype feature aus sprachen wie javascript, neue methoden zu einer bestehenden klasse hinzuzufügen und auch bestehende funktionen zu überschreiben. vl wäre es auch toll wenn o.f() und f(o) identisch wären... ich weiss nicht was mir da am besten gefallen würde. ich weiss nur, dass mir diese trennung member <-> freistehend nicht wirklich gefällt
@audacia:
ja, so etwas wie extension methods. class helpers kenne ich nicht.
-
Shade Of Mine schrieb:
zB list::sort versus std::sort. natürlich macht es sinn dass eine list ein eigenes sort anbietet, aus einer technischen sicht, aber wenn ich das ding nur sortieren will, ist mir das eigentlich egal. wobei das jetzt von der signatur her ein dummes beispiel ist.
Im Normalfall löst man so etwas über Spezialisierung/Überladung. Mir sind einige Fälle bekannt in denen das auch in der Praxis gut klappt.
Der Grund warum es in diesem konkreten Fall glaube ich nicht anders geht, ist dass du zum Sortieren das std::list Objekt selbst brauchst und dieses nicht aus den Iteratoren alleine bestimmen kannst.
Bei Klassenerweiterungen welche uneingeschränkt Zugriff auf die privaten Daten haben geht dir die Kapselung leider kaputt und ab einem gewissen Komplexitätsgrad deines Programms geht es einfach nicht mehr ohne. Das Problem ist halt, dass wenn du deine Klasseninterna änderst du Gefahr läufst, dass alle Erweiterungen zerbrechen.
Ob jetzt wirklich jede einzelne Klasse derart abgeschottet werden muss wie es C++ macht ist aber auch nicht klar. Mir gefällt das package Zugriffsrecht aus Java ganz gut. Das macht die Kapsel ein wenig größer, so dass eine handvoll Klassen rein passen aber nicht zu groß, als dass man Wartungsprobleme kriegen würde. Dadurch braucht man auch 90% der friends nicht mehr.
-
Mist.
Ich habs komplett verpasst.
http://www.hsr.ch/Agenda.6479.0.html?&uid=45&tx_nmagenda_pi_agenda_detail[view]=detail&cHash=640412452a@Dravere: Warst du da?
-
drakon schrieb:
@Dravere: Warst du da?
Habe angefragt und mitgeteilt bekommen, dass meine Anwesenheit unerwünscht wäre, daher bin ich nicht gegangen. Habe mich auch die ganze Woche aus Protest mit C# und Lua beschäftigt
Grüssli
-
Dravere schrieb:
drakon schrieb:
@Dravere: Warst du da?
Habe angefragt und mitgeteilt bekommen, dass meine Anwesenheit unerwünscht wäre
Die Vorträge sind öffentlich zugänglich, die Teilnahme ist kostenlos.
Aus dem Link oben.
-
Ben04 schrieb:
Und jetzt mal ehrlich: Hast du bei der private-Geschichte überhaupt versucht ein Beispiel zu basteln, das die Kapselung bricht? Wenn nicht dann ist mein Gebashe gerechtfertigt.
Im Zusammenspiel mit virtuellen Funktionen kann man damit hübsch Unfug treiben.
Und, wenn man die Implementierung kennt, also die Signaturen von privaten Funktionen kennt, kann man auch mit Overload-Resolution schlimme Dinge machen.
-
drakon schrieb:
Mist.
Ich habs komplett verpasst.
http://www.hsr.ch/Agenda.6479.0.html?&uid=45&tx_nmagenda_pi_agenda_detail[view]=detail&cHash=640412452a@Dravere: Warst du da?
*g* Ich war da, am SWEN Talk...
