spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Nur ganz kurz:
Wer eine Library benutzt muss sich auch damit beschäftigen, wie sie funktioniert. Aber letztendlich kann man dem User schon einiges erleichtern, wenn man die Speicherverwaltung nicht aus den Händen gibt. D.h. lass den User die Library Objekte selbst erzeugen, wenn er sie braucht, aber gib keine Internen Objekte nach außen, schon gar nicht als Raw Pointer.
Das mag zwar zuerst ein wenig seltsam klingen, aber letztendlich werfen Raw Ptr immer Fragen auf. Besten falls stellt er sich die Frage nicht, wer jetzt nun für das Aufräumen verantwortlich ist, schlimmsten falls denkt er, er müsste es selbst machen...
Wenn es denn unbedingt sein muss, das Objekte heraus gegeben werden, dann als Referenz. Sollte es zu irgend einem Zeitpunkt tatsächlich vorkommen können, dass du eigentlich gerne einen nullptr zurück geben würdest, schmeiß ne Exception.
Wenn du allerdings Objekte erstellst, die man außen benutzen soll, dann eben direkt auf dem Stack oder per smart ptr.

PS: Ich rede hier tatsächlich von eigenständigen Modulen, und nicht irgendwelche Pattern oder Templates die einen ganz anderen Sinn haben.

Zitat von »anti-freak«

Wer eine Library benutzt muss sich auch damit beschäftigen, wie sie funktioniert.

Deshalb gehört für mich zu einer guten Library/Framework eine gute Dokumentation. Ich hasse es, sich über 1000 Beispiele auf 1000 Verschiedenen Webseiten in die Library/Framework einzuarbeiten, weil die Doku gerade mal aus doxygen generierten Doku besteht.

Ne ordentliche Doku ist wichtig. Offene Quellen sind auch wichtig, eine reine Prebuilt-Distribution würde bei der Konkurrenz heutzutage nicht mehr akzeptiert werden. Damit zusammenhängend ist aber auch ein Thema, das mir besonders am Herzen liegt: ordentliche Baubarkeit. Ich muss da mal mein altes Lieblingsprojekt als Gegenbeispiel heranziehen: Assimp. War mal ein "Nimm die zwei Verzeichnnisse und baue"-Projekt. Inzwischen gibt's irgendwelche Versionsstrings, die aus nem Skript erzeugt werden, eine bunte Mischung aus ordentlichen ".../relativ"-Includes und globales <bla>-Includes und Dependencies, die auch global angesaugt werden. Mit dem Ergebnis, dass man außer über das CMake vorneweg keine Chance mehr hat, einen gesunden Buildprozess aufzusetzen. Ich kenne mich zum Glück noch genug aus, um es trotzdem autark baubar zusammen mit den anderen Libs aus dem Subversion purzeln zu lassen.

Ist aber zugegebenermaßen ein Luxusproblem. "Wenig/keine Dependencies" ist auch so ein Luxusproblem. Das kriegt man aber eh alles vollautomatisch, wenn man sich an die Grundregel einer Lib hält: löse nur ein Problem, aber das löst Du ordentlich. Die Lib muss sauber funktionieren und einen guten Job machen. Und zwar nur genau diesen einen Job. Ein buntes Sammelsurium an zusätzlichen Herumalbereien interessiert nur den Libautoren, alle anderen fluchen eher.

Stimmt, Assimp wollte ich mir mal ansehen. Ich hab die Lib aber verworfen als ich sie nicht mal gebaut bekommen hatte.

Für mich als VS User ist es ideal wenn es eine Solution gibt die ich bauen muss und die Binaries in einem Ordner rauspurzeln.

Ich arbeite aktuell mit einem Framework, welches nahezu ein Paradebeispiel für ein schlechtes Framework ist.
Hintergrund ist der, dass die Entscheider, welche dieses Framework eingekauft haben leider die Entwickler bei eben dieser Entscheidung nicht mit einbezogen haben und somit einige wichtige Punkte einfach nicht beachtet haben.

Also, schlechtes Framework:
- Aufgaben, welche ohne dieses Framework recht einfach zu lösen wären werden durch das FW unnötig verkompliziert
- Fehlende oder schlechte Doku (wurde aber bereits gesagt)
- Hartcodierte Werte, die den Entwickler ewig nach Fehlern in seinem Sourcecode suchen lassen, obwohl sich später herausstellt, dass der Fehler im FW liegt...
- Schlechter oder Fehlender Support (bei Closed Source Frameworks)

und sicher noch einige mehr...

Ja, solche Entscheider sind immer die tollsten. Zu 99% halten die sich zumindestens für die tollsten.