Property Set Library (PSL) - Vorstellung

vultur_gryphus

Hallo Leute,

ich will auf diesem Wege eine Library von mir einem breiteren Publikum präsentieren. Nach langer Entwicklungszeit, habe ich endlich meine C++ Container Library online gestellt. Das ganze unter MPL 1.1 auf SourceForge.

Die Library entstand in Eigenregie, aber es wäre schön, wenn sich dafür jetzt weitere Entwickler dafür interessieren. Qualität und Nutzbarkeit steigern, Bugs finden etc.

Feel free to send feedback!!! Und wäre natürlich super, wenn der ein oder andere auch einsteigt und Beiträge leisten kann.

Home der "Property Set Library" ist hier: http://psl.sourceforge.net

Informationen und Details sind natürlich dort zu finden, ansonsten kopiere ich einfach mal eine Kurzbeschreibung (siehe unten!)

Schöne Grüße!

----

The Property Set Library (PSL) is a template-based C++ container library providing value observation, event calling, thread-safety, garbage collection, serialization, object persistence, reflection and other accompanying features.

Hem... das Feedback ist bisher ziemlich... mager. Kein Wunder! Wofür ist das Zeug gut? Habe mir die ersten Seiten des Tutorial angeschaut, aber *klick* hats bei mir nicht gemacht.

Also Werbefachmann solltest du nicht werden.

Warum ist dein Buch so teuer?

Mr. N

Basically, there is no problem using references with properties. Only within class definitions property references must not be used.

Wieso? Das sollte an der Stelle IMHO angedeutet werden. (Bin grad beim Lesen des Tutorials.)

Mr. N

However, in case it is caught automatically, the PSL tries to print the error before continuing processing the code normally.

WTF?

.filmor

Ich find die Semantik deiner Properties etwas „gewagt“. Sie benutzen operator->, also sollte meines Erachtens die Zuweisung auch über *prop erfolgen.

Um zu verhindern, dass Instanzen per new erzeugt werden (weshalb auch immer das nötig ist…) könntest du den operator new überladen. Entsprechendes für operator& (wobei das wohl so böse ist, dass du besser überdenken solltest, ob nicht eine echte Bezeigbarkeit doch das bessere wäre).

Bei Tutorial.3.5 willst du wohl eher undefined statt unexpected haben, das ist eher C++-Jargon. Unexpected deutet eher darauf hin, dass dann eine Exception fliegt.

3.8: Wenn base_exception (wofür das Präfix psl?) auf std::exception getypedeft wird hat es aber kein getMessage. Das ist irgendwie unklar.

Weiter hab ich jetzt nicht gelesen

Mr. N schrieb:

However, in case it is caught automatically, the PSL tries to print the error before continuing processing the code normally.

WTF?

Im Destruktor find ich das halbwegs legitim.

vultur_gryphus

Hallo,

und schonmal danke für das "erste" Feedback. Das Lesen des "Tutorials", das leider nicht so genannte werden sollte, da es meiner Ansicht nach etwas anderes geworden ist, ist nicht sehr einfach.

Man sollte vielleicht zuerst die späteren Kapitel lesen, damit einem ein Licht aufgeht, wofür man properties brauchen kann. Das Manual ist leider nicht so aufgebaut, um von vorne nach hinten lesen zu können, und vor allem in den ersten Kapiteln stecken Details, die zur eigentlichen Benutzung zunächst einmal irrelevant sind.

Hem... das Feedback ist bisher ziemlich... mager. Kein Wunder! Wofür ist das Zeug gut?

Nunja, sehr seltsame Frage. Ich kann hier nur z.B. auf die Featureliste verweisen. Und wer diese Features nicht braucht, braucht sie halt nicht.

Also Werbefachmann solltest du nicht werden.

Nein, sollte ich tatsächlich nicht. Aber vielleicht erkennt man ja an der Komplexität der Arbeit, dass man nicht einfach die perfekte Dokumentation schreiben kann, die auch jeder in 5 Minuten versteht. Ich nehme Hilfe gerne an, und suche diese auch.

Warum ist dein Buch so teuer?

Darauf habe ich keinen Einfluss, tut mir leid!

Basically, there is no problem using references with properties. Only within class definitions property references must not be used.

Wieso? Das sollte an der Stelle IMHO angedeutet werden. (Bin grad beim Lesen des Tutorials.)

Ja, stimmt, es sollte angedeutet werden. Ich bin aber sowieso schon unglücklich dass viel zu viele Details in den Anfangskapiteln stecken. Man sollte sich nicht zu lange damit aufhalten. Wie man am ersten Feedback erkennt, kann sowieso niemand den wahren Nutzen der Library erkennen, was meiner Meinung nach ein großes Problem ist.

However, in case it is caught automatically, the PSL tries to print the error before continuing processing the code normally.

WTF?

Im Destruktor find ich das halbwegs legitim.

see http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.3

Ich find die Semantik deiner Properties etwas „gewagt“. Sie benutzen operator->, also sollte meines Erachtens die Zuweisung auch über *prop erfolgen.

Ich hätte mir gewünscht dass C++ hier ähnliche Operatoren wie "->" bietet, die problemlos überladen werden können. Einer allein, nämlich "->", ist gar nicht genug, da ich allein bei Link Properties noch einen anderen Zugriffsoperator gebraucht hätte.

Aber gut, ich habe das in den Jahren alles reiflich überlegt. Aber wenn es bessere Ideen gibt (bitte Beispiele), dann wäre das natürlich auch toll.

Bei Tutorial.3.5 willst du wohl eher undefined statt unexpected haben, das ist eher C++-Jargon. Unexpected deutet eher darauf hin, dass dann eine Exception fliegt.

Danke!

3.8: Wenn base_exception (wofür das Präfix psl?) auf std::exception getypedeft wird hat es aber kein getMessage. Das ist irgendwie unklar.

getMessage wird v.a. dann benötigt, wenn NICHT auf std::exception getypedeft wird (CodeGear-Compiler, VCL Klassen). Ansonsten habe ich die Methode halt einfach in der Klasse gelassen.

vultur_gryphus schrieb:

Man sollte vielleicht zuerst die späteren Kapitel lesen, damit einem ein Licht aufgeht, wofür man properties brauchen kann. Das Manual ist leider nicht so aufgebaut, um von vorne nach hinten lesen zu können, und vor allem in den ersten Kapiteln stecken Details, die zur eigentlichen Benutzung zunächst einmal irrelevant sind.

Dann solltest du das Tutorial ändern, und das was mir zeigt, worfür es gut ist, zu Anfang bringen. Oder wie wäre es mit einem Fallbeispiel zu Anfang? (ohne Code oder nur Pseudocode) Ich habe wie gesagt versucht mich dafür zu interessieren, konnte aber nichts interessantes finden.

Nunja, sehr seltsame Frage. Ich kann hier nur z.B. auf die Featureliste verweisen. Und wer diese Features nicht braucht, braucht sie halt nicht.

OK, habs nochmal angeschaut. Da stehen tatsächlich ein paar Dinge drin, die mir was sagen. (Reflection, AOP u.a.) Sollte man wie gesagt besser verkaufen. Hatte auch hauptsächlich das Tutorial angefangen, und dort kam eigentlich nichts was einen Library-Anwender animiert, einen Nutzen zu finden (Fallbeispiele fehlen irgendwie).

.filmor

vultur_gryphus schrieb:

Ich find die Semantik deiner Properties etwas „gewagt“. Sie benutzen operator->, also sollte meines Erachtens die Zuweisung auch über *prop erfolgen.

Ich hätte mir gewünscht dass C++ hier ähnliche Operatoren wie "->" bietet, die problemlos überladen werden können. Einer allein, nämlich "->", ist gar nicht genug, da ich allein bei Link Properties noch einen anderen Zugriffsoperator gebraucht hätte.

Nuja, aber es ist nunmal so, dass der gemeine C++-Programmierer annimmt, dass wenn er op-> benutzt, er es mit was „zeigerartigem“ zu tun hat, insbesondere auch op* anständig überladen ist (denn es sollte gelten (*obj).member <=> obj->member) und darüber auch die Zuweisung gemacht wird.
So ähnlich habe ich das auch bei einer Klasse für verspäteten Konstruktoraufruf gemacht.

Ist ja hammermäßig!! Ich hatte eigentlich vor 3 Jahren mal was ähnliches vor. Aber hab dann aufgehört als ich gemerkt habe, dass die Arbeit daran ausufert. Aber Respekt vor dieser Leistung.

Die meisten Sachen darin gefallen mir, auch wenn das ganze zu groß ist um da sofort durchzusteigen. Und es wirkt nicht so als könnte man es in jedem Projekt einsetzen, weil doch z.b. Klassen völlig anders konstruiert sein müssen. Das ist Schade. Daher denke ich nur in einem neuen Projekt zu gebrauchen.

Was mir auch nicht gefällt: Tutorial sollte man dieses Dokument vielleicht nich tunbedingt nennen Vielleicht könntest du da was einfacheres zur Verfügung stellen?

Das mit dem -> Operator geällt mir eigentlich schon. Wenn ich auf so ein Objekt Property zugreifen will, denke ich eigentlich nicht automatisch auf Zeiger. Der C++Builder, man habe ihn seelig, zwang auch irgendwie zu Zeigern bei Objekten. Ok, das waren dann Zeiger, aber naja, jedenfalls habe ich damit kein optisches Problem

finix

Ich hab's nur mal kurz überflogen, aber deine Definition von Garbage Collection scheint einigermaßen kurios zu sein...

vultur_gryphus

Was mir auch nicht gefällt: Tutorial sollte man dieses Dokument vielleicht nich tunbedingt nennen. Vielleicht könntest du da was einfacheres zur Verfügung stellen?

Das ist wahrscheinlich leider richtig. Sobald ich mal etwas Zeit habe, werde ich vielleicht wirkliche (kleine) Tutorials schreiben, die dann auch den Einstieg leicht machen.

Die meisten Sachen darin gefallen mir, auch wenn das ganze zu groß ist um da sofort durchzusteigen. Und es wirkt nicht so als könnte man es in jedem Projekt einsetzen, weil doch z.b. Klassen völlig anders konstruiert sein müssen. Das ist Schade. Daher denke ich nur in einem neuen Projekt zu gebrauchen.

Ja, das ist richtig. Aber vielleicht eignet sich die PSL ja z.B. für ein komplettes Modul eines Gesamtprojekts, etc.

Ich hab's nur mal kurz überflogen, aber deine Definition von Garbage Collection scheint einigermaßen kurios zu sein...

Danke für diese Meinung, aber ich kann das nicht ganz verstehen.

Die PSL bietet keinen Garbage Collector für normale Objekte. Aber für Properties, die eigentlich alle Arten von Daten beinhalten können. Die Link Properties stellen dabei die Zeiger dar.

Es ist zwar Wikipedia, aber das ist auch meine Definition von Garbage Collection:

Garbage-Collection. [Der Begriff] steht für ein Verfahren zur regelmäßigen automatischen Wiederverfügbarmachung von nicht mehr benötigtem Speicher und anderen Betriebsmitteln, indem nicht mehr erreichbare Objekte im Speicher automatisch freigegeben werden.

Auch der von mir benutzte Ansatz reference counting ist ein bekanntes Muster der Garbage Collection:

Referenzzählung. Bei diesem Verfahren führt jedes Objekt einen Zähler mit der Anzahl aller Referenzen, die auf dieses Objekt zeigen. Fällt der Referenzzähler eines Objektes auf null, so kann es freigegeben werden

finix

vultur_gryphus schrieb:

Ich hab's nur mal kurz überflogen, aber deine Definition von Garbage Collection scheint einigermaßen kurios zu sein...

Danke für diese Meinung, aber ich kann das nicht ganz verstehen.

Die PSL bietet keinen Garbage Collector für normale Objekte. Aber für Properties, die eigentlich alle Arten von Daten beinhalten können. Die Link Properties stellen dabei die Zeiger dar.

Wie gesagt, ich habe mir das nur ganz kurz und oberflächlich angeschaut, kann also sein dass der Eindruck teils täuscht. Dass lediglich deine Properties GC'd sind ist auch ersichtlich -- wobei ich mir beim Lesen der Featurelist tatsächlich eher an die Möglichkeit dachte GC'd Klassen zu definieren, was auch wesentlich interessanter gewesen wäre!

Aber: es scheint als wären durch die LinkProperties (sp?) Zyklen möglich, und wenn man sich um die selber kümmern muss, kannst du schlecht von Garbage Collection reden. Wenn es keine Zyklen gibt, oder du doch hin und wieder aufräumst, fällt der Punkt natürlich flach.

Allerdings gibt's da noch die forceGarbageCollection (sp?) Methode, und die ist, der Funktionsbeschreibung nach zu urteilen, ganz definitiv weder geschickt benannt, noch hat sie irgendetwas mit Garbage Collection zu tun. Eher delete/destroy/remove/nuke/sonstwas-Property , aber sicher nicht forceGarbageCollection .

vultur_gryphus

Ja, ich glaube das Problem lag am Überfliegen (und natürlich dass die Dokumentation nicht perfekt ist).

Vor der Featureliste steht "The following list applies to all kind of properties the PSL provides".
Und in der Kurzform ist ja auch von Datencontainern die Rede, die Garbage Collection bieten.
Der erste Satz im Kapitel für Garbage Collection ist: "The PSL also supports garbage collection for properties"

Ja, es ist möglich auch GC'd Klassen zu definieren. Dazu müssen diese dann in einem object property verpackt werden. Und das GC'd Objekt kann dann verwendet werden, solange man eine Referenz darauf hat. Wenn die letzte Referenz aufgegeben wird, so wird das Objekt vom Garbage Collector (der wegen dem Ansatz nicht direkt vorhanden ist) automatisch freigegeben.

Selber drüm kümmern ist "falsch formuliert". Eigentlich muss man beim Allozieren nur angeben, dass ein Objekt garbage collected ist. Der Rest funktioniert automatisch. forceGarbageCollection() ist lediglich dazu da, ein Objekt explizit zu löschen (wobei andere noch vorhandene Referenzen automatisch zurückgesetzt werden). Der Name dieser Funktion ist wahrscheinlich schlecht gewählt, aber einen solchen Namen zu ändern ist wohl eher trivial Also danke für dieses Feedback!

finix

vultur_gryphus schrieb:

Selber drüm kümmern ist "falsch formuliert". Eigentlich muss man beim Allozieren nur angeben, dass ein Objekt garbage collected ist. Der Rest funktioniert automatisch.

Mit "selber drum kümmern" meinte ich eigentlich Zyklen!?

vultur_gryphus schrieb:

forceGarbageCollection() ist lediglich dazu da, ein Objekt explizit zu löschen (wobei andere noch vorhandene Referenzen automatisch zurückgesetzt werden).

Das geht deutlich aus deiner Doku hervor, deshalb sage ich ja, nukeProperty oder so wäre passender. Ein forceGarbageCollection hieße eher "räum jetzt mal den Müll weg, auch wenn's gerade nicht unbedingt Not tut".

vultur_gryphus

Selber drüm kümmern ist "falsch formuliert". Eigentlich muss man beim Allozieren nur angeben, dass ein Objekt garbage collected ist. Der Rest funktioniert automatisch.

Mit "selber drum kümmern" meinte ich eigentlich Zyklen!?

Auch um Zyklen muss man sich nicht selbst kümmern, jedenfalls ist dies das Ziel. Derzeit gibt es hier einen Bug, da kurz vor Veröffentlichung triviale zyklische Links nicht erlaubt waren. Diese Einschränkung habe wieder rausgenommen, da es keinen echten Grund mehr dafür gab. Die Sache mit der Garbage Collection hatte ich vergessen, das Problem ist aber relativ einfach lösbar.

Zyklen werden in der Dokumentation nicht erwähnt. Daher sollte ich hinzufügen, dass Zyklen richtig aufgelöst werden.