Eigene Klassenbibliothek

Nexus

mgaeckler schrieb:

Nexus schrieb:

Warum? Wegen der Syntax?

Ja.

D.h. um array.sum() statt sum(array) zu schreiben, bist du bereit, die ganze Palette an Nachteilen in Kauf zu nehmen, ohne einen einzigen echten Vorteil?
Was sind für dich Kriterien für guten Code?
Wenn ich nun die Summe einer Liste berechnen will, diese aber keine sum -Methode anbietet, kann ich also nicht einheitlich sum(container) schreiben?

mgaeckler schrieb:

Nein, denn dann kann ich einfach eine neue Memberfunktionen einführen.

Erweiterbarkeit heisst also, dass man den Bibliotheksentwickler persönlich benachrichtigt, wenn man etwas erweitern will?
Was machst du, wenn ich den Mittelwert von float s berechnen will?
Oder wenn ich ein ARRAY<double> habe, muss ich das erst in ein ARRAY_OF_DOUBLES umkopieren, bevor ich den Mittelwert berechnen kann?

Ich hoffe, dich mit den Fragen etwas zum Nachdenken anzuregen

volkard

Es ging um Summe und Durchschnitt.
Dazu werden Summe und Anzahl als Attribute gehalten.
Also darum, neben der ARRAY<TYP> auch eine ARRAY_WITH_SUM<TYP> anzubieten. Könnte ein Wrapper um ARRAY<TYP> sein.

DocShoe

hustbaer schrieb:

DocShoe schrieb:

Ohne den Code jetzt schönreden zu wollen, aber wenn das Zeugs gewachsen ist kann ich das schon nachvollziehen.

Das war aber nicht die Frage, die Frage war ob Interesse an der Library bestehen könnte.
Und die Antwort darauf ist wohl nicht abhängig davon wie und warum die Library gewachsen ist.

Nexus schrieb:

DocShoe schrieb:

Ohne den Code jetzt schönreden zu wollen, aber wenn das Zeugs gewachsen ist kann ich das schon nachvollziehen.

Nachzuvollziehen, wie sowas vor zwei Jahrzehnten entstanden ist, ist das eine, aber diese Bibliothek im Jahre 2014 noch zu verteidigen braucht doch einiges an Mut

Nein, es besteht auch die Bitte um Kritik. Und wenn etwas kritisiert wird sollte man sich auch rechtfertigen dürfen, warum man das damals so gelöst hat. Einfach lapidar zu sagen "wirf alles weg und stell deinen kompletten Client Code auf STL konforme Lösungen um" kann´s ja wohl auch nicht sein. Technisch ist das sicherlich ein vernünftiger Vorschlag, aber da keiner von uns weiß, wieviel Client Code angefasst werden muss, ist er praktisch vielleicht nicht sinnvoll.

Ansonsten gehe ich mit euch d'accord (zumindest mit Nexus & hustbaer).

daddy_felix

DocShoe schrieb:

Nein, es besteht auch die Bitte um Kritik. Und wenn etwas kritisiert wird sollte man sich auch rechtfertigen dürfen, warum man das damals so gelöst hat.

Ganz ursprünglich stand die Frage im Raum, ob Interesse an dieser Lib besteht. Und soviel Verständnis ich auch für "historisch gewachsenen" Code habe, ist der Anspruch an eine veröffentlichte Lib doch ein ganz anderer als an eine zur Eigennutzung erstellte.

tntnet

DocShoe schrieb:

Nein, es besteht auch die Bitte um Kritik. Und wenn etwas kritisiert wird sollte man sich auch rechtfertigen dürfen, warum man das damals so gelöst hat. Einfach lapidar zu sagen "wirf alles weg und stell deinen kompletten Client Code auf STL konforme Lösungen um" kann´s ja wohl auch nicht sein. Technisch ist das sicherlich ein vernünftiger Vorschlag, aber da keiner von uns weiß, wieviel Client Code angefasst werden muss, ist er praktisch vielleicht nicht sinnvoll.

Ansonsten gehe ich mit euch d'accord (zumindest mit Nexus & hustbaer).

Du hast sicher recht, dass es für den Autor nicht sinnvoll ist, seinen kompletten Client Code anzupassen. Die Library besteht aber aus einem haufen nicht mehr zeitgemässer Designentscheidungen und daher macht es keinen Sinn, sie in dieser Form zu veröffentlichen. Warum sollte man jetzt anfangen eine Bibliothek zu verwenden, wo schon der Autor selbst sagt, dass dort viele störende Sachen zu finden sind.

Und noch was: man könnte natürlich neben einem non-const operator[] auch einen const operator[] anbieten. Oder eine andere const Zugriffsmethode, so dass man zur Summen- oder Durchschnittsberechnung keinen lesenden Zugriff benötigt. So sieht das eben einfach unprofessionell aus.

mgaeckler

Nexus schrieb:

mgaeckler schrieb:

Nexus schrieb:

Warum? Wegen der Syntax?

Ja.

D.h. um array.sum() statt sum(array) zu schreiben, bist du bereit, die ganze Palette an Nachteilen in Kauf zu nehmen, ohne einen einzigen echten Vorteil?
Was sind für dich Kriterien für guten Code?
Wenn ich nun die Summe einer Liste berechnen will, diese aber keine sum -Methode anbietet, kann ich also nicht einheitlich sum(container) schreiben?

Ich habe diese Funktion genau einmal gebraucht und würde sie, wenn ich danach suche, wahrscheinlich auch nicht so schnell finden. Wenn man das öfters braucht, sind andere Lösungen z.B. mit templates sicherlich besser.

Nexus schrieb:

mgaeckler schrieb:

Nein, denn dann kann ich einfach eine neue Memberfunktionen einführen.

Erweiterbarkeit heisst also, dass man den Bibliotheksentwickler persönlich benachrichtigt, wenn man etwas erweitern will?
Was machst du, wenn ich den Mittelwert von float s berechnen will?
Oder wenn ich ein ARRAY<double> habe, muss ich das erst in ein ARRAY_OF_DOUBLES umkopieren, bevor ich den Mittelwert berechnen kann?

Für den Nutzer, der die Bibliothek nicht selbst weriterentwickelt, ist das sicherlich keine gute Lösung. Korrekt. Bedenke, bisher war Bibliotheks-Entwickler und -nutzer genau eine Person. Es war auch nicht geplant, diese Lib zu veröffentlichen, weshalb die hier angebrachten Überlegungnen bisher keine Rolle spielten.

Nexus schrieb:

Ich hoffe, dich mit den Fragen etwas zum Nachdenken anzuregen

Klar, deshalb habe ich dieses Dokument ja auch schon mal vorab veröffentlicht. Ein paar Sachen der Containerbibliothek werde ich wohl vorher ändern, bevor das ganze rausgeht. Der const index operator ist sicherlich das erste, was gemacht werden muß, da mich die jetztige Lösung schon lange nervt. Nach der vernichtenden (aber auch berechtigten) Kritik hier, ist das erst recht erforderlich.

Die Containerklassen, will ich aber eh nicht so herausstellen, da hierfür der Standard normalerweise ausreichen sollte.

Ich dachte halt eher an das Webzeugs, daß das interessant für andere sein könnte. Da hierüber gar nicht diskutiert wird, nehme ich an, daß das niemand braucht. Dann ist allerdings die Frage, ob der Aufwand für andere Änderungen (wie z.B. ARRAY_OF_DOUBLES durch template funktionen zu ersetzen) nicht eingespart werden kann und die Bibliothek nicht zu veröffentlichen.

mfg Martin

mgaeckler

tntnet schrieb:

Und noch was: man könnte natürlich neben einem non-const operator[] auch einen const operator[] anbieten. Oder eine andere const Zugriffsmethode, so dass man zur Summen- oder Durchschnittsberechnung keinen lesenden Zugriff benötigt. So sieht das eben einfach unprofessionell aus.

So was ähnliches gibt es schon hab's aber vergessen und sum war daher const, was ich vorhin übersehen habe. 8-(

Ich werde auf jeden Fall einen Index-operator einführen der const sein wird und beim Überlauf eine Exception wirft und den bisherigen wahrscheinlich entfernen.

Ich habe grundsätzlich kein Problem damit, falsche Entschedungen zu korrigieren. Kommt halt darauf an, wie lange es dauert, bis der Leidensdruck groß genug ist.

mfg Martin

DocShoe

mgaeckler schrieb:

...
Bedenke, bisher war Bibliotheks-Entwickler und -nutzer genau eine Person.
...

Aha... in dem Fall würde ich mir tatsächlich überlegen, ob ein Code Refactoring nicht doch sinnvoll ist.

Xin

daddy_felix schrieb:

Heute gibt es aber den Standard und heutige Programme sollten diesen auch nutzen. Warum sollte jemand bspw. Interese an deinem STRING haben, wenn er doch std::string verwenden kann?

Ich habe mir die String-Klasse der Lib nicht angesehen, aber ich verwendet selbst eine eigene String-Klasse, die (vereinfacht ausgedrückt) ebenso auf einem selbst geschriebenen Array-Template basiert. Die meisten Funktionen zur Stringverarbeitung liegen in der Array-Klasse, warum sollte ich etwas wie "substr" nicht auch in einem Int-Array nutzen können?
Ich bin auch kein Fan davon, dass sich der Objektorientierte Ansatz (obj.func()) und der generische Ansatz (func<T>( obj )) laufend in die Quere kommen und man erst überlegen muss, ob obj jetzt den Namensraum der Funktion func() definiert und ich func() per IDE vorgeschlagen bekomme oder ob ich func<>() erstmal finden oder halt auswendig wissen muss, ob es ein func<>() für mein obj überhaupt gibt.
Es gibt hier kein Lösung, die nicht auch ein 'aber' besitzt.

std::string ist in meinen Augen manchmal auch eher etwas umständlich zu verwenden. Es hat den Vorteil, dass man standardkonform ist, aber konform ist nicht immer Komfort. Arbeitet man viel mit Strings, relativiert und amortisiert sich der Mehraufwand einer eigenen Implementation.

Mir scheint, dass es einiges an Kritikpunkten an der Lib gibt. Nichtsdestotrotz finde ich es durchaus interessant auch mal in Implementationen zu gucken, die nicht std sind. Nicht alle guten Ideen schaffen es in std und manchmal ist es auch gut, wenn man mal was anderes sieht als std, schließlich hat man auch nicht immer std-Probleme zu lösen.

@mgaeckler: Du wirst mit einer solchen Lib nicht unbedingt viele Freunde gewinnen und ich glaube auch nicht wirklich, dass sie außerhalb Deiner Software viele Anwender finden wird. Entweder man nimmt spezielle, selbstgeschriebene Container, die man auch speziell für seine Lösung braucht, oder man hat kein spezielles Problem und sollte std nehmen.
Dinge wie Const-Correctness würde ich auch als Mindestvoraussetzung für eine Lib ansehen. Grundsätzlich spricht aber nichts dagegen, die Lib auch mal zur 'Inspiration' zu veröffentlichen, selbst wenn Const-Correctness nicht implementiert ist.
Es schadet nicht, wenn jemand sich Quelltext ansieht und daraus lernen kann. Man kann durchaus sehen, wie Du Container aufbaust spezialierst. Aber zum Lernen gehört zähle ich auch die Erkenntnis, dass es Dinge gibt, die man in den eigen Implementierung verbessern kann. Wenn Dinge nur perfekt wären, wenn sie std sind, dürfte die meiste Software nicht veröffentlicht werden.
Bevor die Lib also wirklich auch eine Referenz für Deine Programmierkünste darstellen würde, solltest Du einige Dinge noch überarbeiten - ansonsten würde ich mich durchaus gerne inspirieren lassen, also mich durchaus freuen, wenn Du die Lib veröffentlichst.

mgaeckler

DocShoe schrieb:

mgaeckler schrieb:

...
Bedenke, bisher war Bibliotheks-Entwickler und -nutzer genau eine Person.
...

Aha... in dem Fall würde ich mir tatsächlich überlegen, ob ein Code Refactoring nicht doch sinnvoll ist.

Es ist schon beschlossene Sache, daß die schlimmsten Designentscheidungen erst mal korrigiert werden, bevor ich die Bibliothek veröffentliche.

An dieser Stelle möchte ich mich bei allen bedanken, für die Kritik. Vieles habe ich zwar schon vorher auch gesehen, ich hätte jetzt aber nicht gedacht, daß die Reaktionen so heftig ausfallen. Dann müsst Ihr halt noch 'ne Weile warten.

mfg MArtin

hustbaer

Was mich wundert, ist, warum man eine 20 Jahre alte Library noch für neue Projekte verwendet.
Ich hätte da schon längst auf std::vector/string/... umgestellt.

Alte Projekte die weitergepflegt werden müssen muss man deswegen ja nicht anfassen. Zumindest nicht, so lange sich der "Pflegeaufwand" für diese alten Projekte in Grenzen hält.

Und die Dinge die auch trotz Standard-Library noch nützlich sind, wie vielleicht der XML Parser, kann man entweder durch fertige Libraries ersetzen (z.B. TinyXML). Oder, wenn man sich nix fertiges findet mit dem man sich anfreunden kann, auf die Standardklassen (std::string, ...) umstellen, so dass keine Abhängigkeiten zu den alten, obsolet gewordenen STRING, ARRAY etc. Klassen mehr bestehn.

Ich meine, wie soll man jemals lernen modernes C++ zu schreiben, wenn man immer noch alten Code weiterverwendet der voll von schlechten Designentscheidungen ist? Solchen Code zu verwenden/schreiben muss einem Schmerzen bereiten, sonst entwickelt man sich nie weiter.

Achja, nochwas: Was die sum/average Memberfunktionen angeht: die einzige Berechtigung diese als Member auszuführen ist mMn. wenn man sie als Member performanter implementieren kann -- und das dann auch tut. Wobei die offensichtliche Möglichkeit die Summe + Anzahl immer mitzuführen bei double s eine ganz schlechte Idee ist (NaNs, Rundungsfehler etc.).

Nexus

Xin schrieb:

Es schadet nicht, wenn jemand sich Quelltext ansieht und daraus lernen kann.

Doch, und zwar massiv. Das Ausmass davon erkennst du daran, wie viele Leute dank Wolfsbüchern nicht richtig C++ können.

mgaeckler schrieb:

Es ist schon beschlossene Sache, daß die schlimmsten Designentscheidungen erst mal korrigiert werden, bevor ich die Bibliothek veröffentliche.

Es mag jetzt etwas harsch klingen, aber: An deiner Bibliothek gibts nicht viel zu reparieren. Da muss das grundlegende Design neu gemacht werden. Viel moderner, ohne Vererbung, im STL-Stil und auch mit ihr kompatibel. Wo möglich würde ich auch die STL als Backend einsetzen. Das ist die einzige Möglichkeit, das 21. Jahrhundert zu erreichen.

Ob sich der Aufwand lohnt, ist eine andere Frage... Aber du solltest nicht das Gefühl haben, dass es mit kleinen Fehlerbehebungen wie Const-Correctness getan ist. Das ganze Java-Paradigma muss von Grund auf ausgewechselt werden.

SeppJ

Nexus schrieb:

Da muss das grundlegende Design neu gemacht werden. Viel moderner, ohne Vererbung, im STL-Stil und auch mit ihr kompatibel.

Dann hat er die STL nachprogrammiert.

Nexus

SeppJ schrieb:

Dann hat er die STL nachprogrammiert.

Darum "STL als Backend wo möglich"... wenn nur noch sum() und average() als freie Funktionen bleiben, ist der Aufwand umso kleiner

@mgaeckler: Sich zu überlegen, wie die gleiche Funktionalität unter Benutzung der STL realisiert werden könnte, ist so oder so eine gute Idee. Dann würdest du wahrscheinlich einige der hier genannten Punkte genauer verstehen.

Nexus schrieb:

im STL-Stil und auch mit ihr kompatibel. Wo möglich würde ich auch die STL als Backend einsetzen. Das ist die einzige Möglichkeit, das 21. Jahrhundert zu erreichen.

Ach, STL ist so 98er ...

SeppJ

Nexus schrieb:

SeppJ schrieb:

Dann hat er die STL nachprogrammiert.

Darum "STL als Backend wo möglich"... wenn nur noch sum() und average() als freie Funktionen bleiben, ist der Aufwand umso kleiner

sum gibt's ja schon als accumulate und ob man jetzt eine extra Funktion für eine Division braucht? Vor allem da der richtige Rückgabetyp und der exakte Typ der Division bei average ein wenig unklar ist, wenn man generisch programmieren möchte.

hustbaer

Nexus schrieb:

SeppJ schrieb:

Dann hat er die STL nachprogrammiert.

Darum "STL als Backend wo möglich"... wenn nur noch sum() und average() als freie Funktionen bleiben, ist der Aufwand umso kleiner

sum() und average() und evtl. seine XML/HTML Klassen.

Xin

Nexus schrieb:

Xin schrieb:

Es schadet nicht, wenn jemand sich Quelltext ansieht und daraus lernen kann.

Doch, und zwar massiv. Das Ausmass davon erkennst du daran, wie viele Leute dank Wolfsbüchern nicht richtig C++ können.

Ich habe Assembler aus einem Buch gelernt in dem Programme abgedruckt waren, die nicht funktionierten. Trotzdem funktionierten meine Programme.

Wer irgendwas für die endgültige Wahrheit hält, hat das wichtigste nicht gelernt.
Wer denkt, dass er aus einem modernen Buch richtiges C++ lernen kann, wird enttäuscht werden, weil das in 5-10 Jahren eben auch kein "richtiges" C++ mehr ist.
Eine Information muss nicht korrekt oder perfekt sein, um den eigenen Horizont zu erweitern. Und wer nichts anderes zulässt, wird kaum über einen großen Horizont verfügen.

Jedes Buch, jedes Tutorial und jedes Posting in diesem Forum ist eine Meinung, eine Perspektive, eine Inspiration - wobei einige hier schreiben, als hätten sie die Wahrheit für sich gepachtet.

Ich habe ein Buch von Jürgen Wolf. Ich finde es inspirierend. Ich finde auch Bücher von Kerningham inspirierend. Und in beiden Fällen ist es nicht die endgültige Wahrheit. Und veraltet sind sie auch.

Genauso kann ich mir eine alte Lib angucken und darin Dinge finden, die vom ersten Eindruck heute vielleicht altmodisch aussehen. Und morgen vielleicht State of Art sind.

volkard

Xin schrieb:

Wer irgendwas für die endgültige Wahrheit hält, hat das wichtigste nicht gelernt.

"Alle Generalisierungen sind falsch."

Xin schrieb:

wobei einige hier schreiben, als hätten sie die Wahrheit für sich gepachtet.

*meld*

Xin schrieb:

Ich habe ein Buch von Jürgen Wolf. Ich finde es inspirierend.

Es gibt nicht viele Ledernacken wie uns. Die meisten gehen davon einfach kaputt.

Xin schrieb:

Ich finde auch Bücher von Kerningham inspirierend.

Mehr als das.

Xin schrieb:

Genauso kann ich mir eine alte Lib angucken und darin Dinge finden, die vom ersten Eindruck heute vielleicht altmodisch aussehen. Und morgen vielleicht State of Art sind.

Jo, kommt vor. Hier wohl nicht.

edit: Beispiele:
Rekursive Abstiegscompiler: Offensichtlich das, was man im Sinne hat, aber ein Funktionsaufruf/-rücksprung kostet "Sprungziel lesen, IP schreiben, SP inkrementieren, IP=Sprungziel, SP für lokale Variablen erhöhen"/"SP wieder erniedrigen, Rücksprungziel lesen, SP dekrementieren, IP=Rücksprungziel" oder so, unendlich teuer, man baut 50 Jahre lang endliche Automaten und so, um mehr Speed zu haben. Nu haben die Prozessorbauer in die Befehle call/ret so hammerviele Transistoren reingesteckt, der native Stil ist auf einmal besser.
Ein Thread pro Connection: Dauert noch ein Weilchen, ist aber absehbar und zwangsläufig.

hustbaer

So.

Nachdem ich jetzt selbst mal in das PDF reingeguckt habe...: da sind ja noch viel mehr Sachen drinnen als die Strings und Container.
u.A. nen HTTP Server (oder zumindest die Basis dafür), nen Soap Client usw.

=> Könnte schon einige Dinge geben wo man sich 'was abgucken kann. Gibt ja nicht nur das Design als Ganzes. Manchmal sieht man auch in der Implementierung Dinge die man selbst viel komplizierter gemacht hätte.