Eigene Klassenbibliothek

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.

mgaeckler

Nexus schrieb:

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.

Was meinst Du mit Java-Paradigma? Wegen den vielen Ableitungen? Ich programmiere kaum mit Java, daher denke ich nicht, daß mich diese Sprache allzusehr beeinflußt hat.

mfg Martin

volkard

mgaeckler schrieb:

…

Sachen, die man jetzt nicht mehr in C++ macht, die man aber in Java oft sieht. Das heißt nicht, daß Du sie von Java abgeschaut hättest. Und daß Du nicht bei Java geschaut heißt, beweist nicht, daß die Lib nicht an manchen Stellen javaesk wäre.
Auch wills mir erscheinen eher als 80-er-Jahre-Stil. Daran ändert es nichts, wenn Du die Lib erst nach 1990 gebaut hast, dann hattest Du eben da schon die nicht frischesten Bücher.

mgaeckler

Hallo,

ich habe jetzt die Bibliothek ein wenig überarbeitet, die Doku entsprechend angepasst und auch ein wenig erweitert:
http://www.cresd.de/edv/ger/Products/gaklib.pdf

Wer mag, kann auch schon mal einen Blick auf die Quellen werfen:
http://www.cresd.de/edv/archiv/GAKLIB.zip (12.28MB)

Die Containerbibliothek ist, auch wenn der eine oder andere sich das anders wünschte, nach wie vor enthalten. Der Aufwand sie zu entfernen, ist mir derzeit noch zu groß.

Interessant ist, daß die Standardbibliothek meiner Borland Compiler langsamer ist, wie meine eigene. Mit GNU unter Linux und Mac OS X ist es aber umgekehrt. Bei Visual Studio 2010 sind die Ergebnisse in beiden Fällen jenseits von gut und böse (hab extra wegen denen die Datenmenge von 10000 auf 1000 reduziert, damit der Test in endlicher Zeit endet) Muß aber dazu sagen, daß ich mit VS2010 nur 'ne Debugversion gebaut habe und VS2010 setzt dann noch ziemlich viel Testcodes ein, was zwar eine praktische Sache ist, eine Performanzaussage kann man damit aber nicht machen.

Über konstruktive Kritik, freut sich wie immer

der Martin

volkard

Danke für die UML-Diagramme. Jetzt verstehe ich die Klassen viel besser.
Viel Erfolg!

mgaeckler

volkard schrieb:

Danke für die UML-Diagramme. Jetzt verstehe ich die Klassen viel besser.
Viel Erfolg!

Ich hoffe das war nicht ironisch gemeint Bei der UML-Spec hätten nämlich die Pfeile genau anders rum gehen müssen. Das finde ich aber nicht sehr intuitiv.

Wie dem auch sein, nicht wundern das das Archiv doch nicht 12 MB groß ist, ich vergaß die Intelisense DB von Visual Studio zu löschen. jetzt sind es nur noch ca 600 KB.

mfg Martin