Implementiert ihr Datenstrukturen und Algorithmen selbst?



  • Ich beschäftige mich gerade mit Datenstrukturen und Algorithmen(Bäume, Graphen, Traversieren, Suchen, Greedy, Divide and Conquer usw). Jetzt frage ich mich, ob das in der Praxis auch von euch implementiert wird, oder ob ihr da immer Libs nutzt?
    Wenn ihr Libs nutzt, würde mich interessieren welche das so sind und wenn ihr das selbst implementiert, dann würde mich interessieren ob ihr da die sonst so verpönten Zeiger einsetzt, also ob das dann ein Gebiet wäre, wo man tatsächlich noch regelmäßig mit rohen Zeigern hantiert?



  • Ich schreibe die einfachen Datenstrukturen (also was du erwähnt hast) immer selber, das geht viel zu schnell als dass man sich ernsthaft Gedanken darüber machen muss, welche Lib man verwendet (also was in der STL ist, verwende ich und nicht-triviale Algorithmen wie Boyer-Moore-Horspool nehme ich aus Boost).

    Zeiger brauche ich dabei kaum, bei Graphen nimmt man einfach ein vector<node> und jeder node hat ein vector<int> als Adjazenzliste, wobei der Index auf den vector<node> zeigt.



  • Meistens reichen irgendwelche kleineren Sachen. Rohe pointer kommen erst dann zum Einsatz, wenn es wirklich performancekritisch ist und werden selbst dann noch so gut wie moeglich gekapselt, denn in den meisten Faellen reicht immer noch unique_ptr aus.


  • Mod

    Marthog schrieb:

    Rohe pointer kommen erst dann zum Einsatz, wenn es wirklich performancekritisch ist und werden selbst dann noch so gut wie moeglich gekapselt, denn in den meisten Faellen reicht immer noch unique_ptr aus.

    Das klingt komisch. Die Frage roher Pointer vs. Smartpointer hat nichts mit Perfomance zu tun, sondern mit der Programmlogik. Ein roher Pointer + die nötige Logik um das gleiche zu erreichen, wie ein passender Smartpointer ist exakt so performant wie eben dieser Smartpointer. Und ein roher Pointer ohne diese Logik, wenn die Programmlogik eigentlich nach einem Smartpointer verlangt, ist vor allem eines: Falsch. Niemanden interessiert es, wie schnell dein falsches Programm ist.

    Und in den meisten Fällen sind Smartpointer sowieso auch noch genau so schnell wie rohe Pointer, da die Programmlogik, die meiste Zeit gar nicht aktiv ist. Bloß kannst du mit dem Smartpointer bei der Programmierung gar nichts mehr falsch machen, im Gegensatz zum rohen Pointer. Und wenn du die fehlende Logik dem rohen Pointer hinzu fügst, hast du bloß den Smartpointer (wahrscheinlich schlecht) nachprogrammiert.

    Es gibt viele Fälle, in denen man rohe, besitzlose Zeiger brauchen kann, aber diese Entscheidung ist nie eine Frage der Performance, sondern immer von dem, was nötig ist.



  • Citizen42 schrieb:

    dann würde mich interessieren ob ihr da die sonst so verpönten Zeiger einsetzt, also ob das dann ein Gebiet wäre, wo man tatsächlich noch regelmäßig mit rohen Zeigern hantiert?

    Klar, innerhalb von (besitzenden) Bäumen und Listen gehören rohe Zeiger. Bei userseitiger Vergeßlichung kann ja nix passieren.



  • Also wenn ich das richtig überblicke, haben wir jetzt 3:1 für Smartpointer, richtig? Zudem werden von euch nicht so komplexe Strukturen selbst gebaut.

    Ich lerne derzeit nach den Online-Vorlesungen über Informatik II mit C++ der Uni Tübingen und dort wird halt nur mit rohen Zeigern gearbeitet. Da die Aufnahmen von 2013 sind und C++11 dort schon der aktuelle Standard war, kamen mir diese Fragen in den Sinn.



  • Citizen42 schrieb:

    Da die Aufnahmen von 2013 sind und C++11 dort schon der aktuelle Standard war, kamen mir diese Fragen in den Sinn.

    Geh nicht davon aus, an einer Hochschule in einer Grundlagenvorlesung was aktuelles zu lernen.



  • Ja, dann ist das wohl so.

    Es geht mir auch im Prinzip nur darum, die Konzepte der Informatik zu verstehen und ein paar interessante Techniken auch mal selbst nach zubauen. Ich hoffe dadurch ein besserer Hobbycoder zu werden, da solche Einblicke den Horizont schön erweitern. Dass hier noch C++ verwendet wurde, hob meine Lern-Motivation nochmals in die Höhe, da ich die Sprache ja eh gerade lerne.


Log in to reply