3. Boost Probleme

Boost Probleme

  • ?

    Mh, ok Danke!

    Diese Hilfeseite habe ich auch schon gefunden, aber ich finde sie irgendwie bißchen schwer zu lesen. Wenn ich z.B. die "Doku" von ptr_map aufschlage:
    http://www.boost.org/doc/libs/1_39_0/libs/ptr_container/doc/ptr_map.html
    steht da im Grunde garnichts.
    Ich hätte halt gerne eine Liste aller Methoden, wie z.B. hier: http://www.cppreference.com/wiki/stl/vector/start

    0
  • Administrator

    anfänger8 schrieb:

    steht da im Grunde garnichts.

    Es steht etwas ganz wichtiges dort, nämlich dass es eine Ableitung einer anderen Klasse ist. Und diesen Baum kann man raufwandern und alle Methoden finden.
    Ich finde die Übersicht dadurch allerdings auch nicht wirklich gut. Mir ist allerdings nicht bekannt, dass es bei den Boost.PointerContainer eine besser Übersicht gäbe.

    Grüssli

    0
  • A

    Ja, ist auf den ersten Blick und für ungeübte Leser nicht gerade super. Aber auf den zweiten Blick sieht man, das es von ptr_multimap_adapter erbt ist, und dann schaut man da entsprechend rein:

    http://www.boost.org/doc/libs/1_39_0/libs/ptr_container/doc/ptr_multimap_adapter.html

    0
  • ?

    Ich finde die Doku ehrlich gesagt scheisse - vor allem für einen Anfänger. Wo seh ich denn da z.B., dass ptr_map einen operator[] hat?
    In der Seite zu ptr_map steht schon mal nichts. Also muss ich mir die Basisklasse anschauen und da find ich wieder nichts. Ich seh noch nicht mal, welche Konstruktoren ptr_map hat.
    Überhaupt vermischt die Doku zu viel "Internas"/Code mit der Hilfe. In der Doku will ich doch sowas wie

    class ptr_multimap_adapter 
    {
    public: // typedefs
        typedef VoidPtrMap::key_type key_type;
        typedef T*                   mapped_type;
        typedef T&                   mapped_reference;
        typedef const T&             const_mapped_reference;
        typedef ...                  value_type;
        typedef ...                  reference;
        typedef ...                  const_reference;
        typedef ...                  pointer;
        typedef ...                  const_pointer;  

    public: // modifiers         
        iterator  insert( key_type& k, T* x ); 
        template< class U >
        iterator  insert( const key_type&, std::auto_ptr<U> x );

    nicht lesen, sondern ÜBERSICHTLICH eine Liste der Methoden sehen, wie z.B. hier:
    http://msdn.microsoft.com/en-us/library/system.windows.forms.panel_members.aspx

    Ich als Anfänger fühl mich da irgendwie etwas aufgeschmissen. Werde boost erst mal doch nicht benutzen.

    0
  • A

    Ich als Anfänger fühl mich da irgendwie etwas aufgeschmissen. Werde boost erst mal doch nicht benutzen.

    Schade das du so schnell aufgibst. 😞 Du projezierst eine Library-Doku auf alle anderen Dokus der Boost Sammlung.

    Bitte bedenke, das Boost eine Library-Sammlung ist, es ist nicht eine Library. Entsprechend unterscheiden sich die Dokus der einzelnen Libs auch in der Qualität. Die Booster versuchen eine hohe Qualität rein zu bekommen, aber es kann auch Libs geben, die vernachlässigt sind. Aber im Großen und Ganzen sind viele Libs gut bis sehr gut dokumentiert.

    Für Anfänger ist vielleicht auch das ein oder andere nicht gleich verständlich. Aber man kann z.B. als Anfänger konstruktiv in der offiziell User-boost-Mailingliste solche Dinge ansprechen.

    Ich würde es mir nochmal überlegen, da du mit Boost wirklich Vorteile erhälst. Und die ptr-Container und dessen Doku sind ein gaaanz kleiner Teil von Boost.

    0
  • N

    Dravere schrieb:

    Weil IntelliSense einfach seit jeher verbuggt ist. Ich persönlich benutze ein kostenpflichtiges Plugin Visual Assist X, um die Funktionalität zu verbessern. Ansonsten helfen nur das Neustarten der IDE oder das löschen der IntelliSense Datenbank.

    Naja, manchmal liegts auch an Boosts Umfang und der Ansicht, dass eine simple Implementierung niemals gut sein kann. Teilweise habe ich diesen Eindruck wirklich.

    Ähnliches hat man beim Debugging. Ich habe es nicht fertig gebracht, Boosts Pointer-Container anständig zu debuggen. Das ist die reinste Hölle, weil man im Debugger etwa fünf Indirektionen durchklicken muss und schlussendlich einen void* -Zeiger vor sich hat, den man nicht lesen kann. Manchmal überlege ich mir echt, ob es da gescheiter wäre, (wenigstens für Debug) etwas eigenes zu basteln oder die STL-Container zu wrappen. Ist dann natürlich auch etwas heikel, wenn sich die Container im Release-Modus anders verhalten.

    Allgemein gefallen mir die Pointer-Container nicht besonders. Exceptionsicherheit ist ja schön, aber meistens verwalte ich darin sowieso nur Klassen, die keine Exceptions werfen. Von daher scheint mir der Preis für meine Fälle oft etwas hoch.

    0
  • ?

    Nexus schrieb:

    Dravere schrieb:

    Weil IntelliSense einfach seit jeher verbuggt ist. Ich persönlich benutze ein kostenpflichtiges Plugin Visual Assist X, um die Funktionalität zu verbessern. Ansonsten helfen nur das Neustarten der IDE oder das löschen der IntelliSense Datenbank.

    Naja, manchmal liegts auch an Boosts Umfang und der Ansicht, dass eine simple Implementierung niemals gut sein kann. Teilweise habe ich diesen Eindruck wirklich.

    Ähnliches hat man beim Debugging. Ich habe es nicht fertig gebracht, Boosts Pointer-Container anständig zu debuggen. Das ist die reinste Hölle, weil man im Debugger etwa fünf Indirektionen durchklicken muss und schlussendlich einen void* -Zeiger vor sich hat, den man nicht lesen kann. Manchmal überlege ich mir echt, ob es da gescheiter wäre, (wenigstens für Debug) etwas eigenes zu basteln oder die STL-Container zu wrappen. Ist dann natürlich auch etwas heikel, wenn sich die Container im Release-Modus anders verhalten.

    Allgemein gefallen mir die Pointer-Container nicht besonders. Exceptionsicherheit ist ja schön, aber meistens verwalte ich darin sowieso nur Klassen, die keine Exceptions werfen. Von daher scheint mir der Preis für meine Fälle oft etwas hoch.

    Ich kann dir nur in allen Punkten zustimmen! Ich bin wirklich ziemlich enttäuscht von boost. Erstmal die Teilweise absolut unübersichtliche und anfängerunfreundliche Doku. Dann finde ich manche Klassen einfach unnötig kompliziert zu bedienen.
    Aber das Schlimmste: Ich wollte mir boost vor allem holen um was zu lernen. Aber wenn ich diesen Code sehe, dann vergehts mir echt. Das alles wirkt einfach nur schrecklich überdesigned und meiner Meinung ist man völlig übers Ziel hinausgeschossen. Anstatt einfach mal ne Klasse simpel zu implementieren hat alles zig Template Parameter, verschachtelte Klassen, nochmal Template Methoden, Policy Templates usw usw. Ich blick da auf jeden Fall null durch.

    Diese "Überdesign" in Verbindung mit der (für mich) echt miesen Doku führten dazu, dass ich mich von boost wieder distanziere. Aber eins hat es doch erreicht: Jetzt gefällt mir sogar die STL ein Stück besser 😉

    0
  • N

    Es ist ja nicht so, dass dieses Design grundsätzlich immer schlecht ist. Im Gegenteil, oft gewinnt man sehr viel Flexibilität dadurch. Nur braucht man diese eben nicht immer, wodurch man Teile der Library vielleicht als ungeeignet erachten mag. Gerade als Anfänger sieht man die Vorteile kaum, wenn man sich mit den entsprechenden Programmiertechniken und Anwendungsfällen nicht auskennt.

    Nicht dass ich falsch verstanden werde: Ich finde Boost in vielerlei Hinsicht extrem nützlich und benutze viele Teil-Bibliotheken in meinen Projekten. Aber dennoch gibt es Dinge, die mir daran nicht gefallen. Aber ganz so tragisch ist das nicht, eventuell überlege ich mir mit der Zeit wie gesagt eigene Implementierungen.

    P.S.: Die Dokumentation finde ich im Allgemeinen überhaupt nicht schlecht. Okay, sie ist vielleicht nicht immmer ganz einsteigerfreundlich, aber bei den Pointer-Containern habe ich eigentlich das meiste auf Anhieb verstanden.

    0
  • A

    anfänger8 schrieb:

    Ich kann dir nur in allen Punkten zustimmen! Ich bin wirklich ziemlich enttäuscht von boost. Erstmal die Teilweise absolut unübersichtliche und anfängerunfreundliche Doku. Dann finde ich manche Klassen einfach unnötig kompliziert zu bedienen.
    Aber das Schlimmste: Ich wollte mir boost vor allem holen um was zu lernen. Aber wenn ich diesen Code sehe, dann vergehts mir echt. Das alles wirkt einfach nur schrecklich überdesigned und meiner Meinung ist man völlig übers Ziel hinausgeschossen. Anstatt einfach mal ne Klasse simpel zu implementieren hat alles zig Template Parameter, verschachtelte Klassen, nochmal Template Methoden, Policy Templates usw usw. Ich blick da auf jeden Fall null durch.

    Diese "Überdesign" in Verbindung mit der (für mich) echt miesen Doku führten dazu, dass ich mich von boost wieder distanziere. Aber eins hat es doch erreicht: Jetzt gefällt mir sogar die STL ein Stück besser 😉

    Boost ist eine Bibliothek, und sollen den Sinn haben wieder verwendbar zu sein. Du kannst jetzt entscheiden, bis zu welchem Grad sowas wiederverwendbar sein soll. Und der max. Grad ist nunmal mit Templates. Das kann man einem Lib-Designer nicht ankreiden.

    Du kannst jetzt als außenstehender unterschiedlich an die Sache rangehen.

    1. Du kannst versuchen das Design und Implementierung zu vestehen.
    2. Du kannst versuchen es "nur" zu benutzen.

    Du willst ersten Weg gehen. Und wenn du dich jetzt darüber beklagst, das du das nicht verstehst, und deshalb alles doof ist, dann hast du ehrlich selber schuld! Weil Du etwas nicht verstehst, sind die anderen dumm?

    Warum gehst du nicht einfach den zweiten Weg? Wofür Boost primär gedacht ist. Ich selber bin "nur" Boost-User und komme deshalb wunderbar damit zu recht. Man muß die Implementierung von Boost nicht verstehen, um es benutzen zu können.

    Das man tausende Template-Parameter usw. verstehen muß, stimmt auch nicht. Die meisten Boost-Libs haben Default-Definitionen, die man einfach so benutzen kann. Oder die Template-Parameter sind meistens so simple wie in der Std-Lib.

    Auch das der Code so crazy aussieht, ist nicht die Schuld der Boost-Entwickler. Ganz im Gegenteil, den verrückten Code gibt es meistens, weil sie versuchen verschiedene Compiler und Plattformen zu unterstützten. Das ist eine sehr komplexe Angelegenheit. Und auch die Boost-Entwickler finden das nicht cool. Die wollen sogar endlich mal die ollen COmpiler wie Borland 5, VC6 usw. los werden, um den Code zu entrümpeln. Dabei sollte man Hochachtung vor Boost haben, wie sie es schaffen, soviele COmpiler und Systeme zu unterstützen und jedem User gerecht zu werden!

    Aber man kann sich auch das Leben schwer machen und den anderen die Schuld geben.

    0

  • Einige Boost Libraries sind IMO wirklich etwas ... schlecht.
    Manchmal die Implementierung, manchmal das Design, manchmal beides.
    Einige sind auch etwas schwer zu verstehen, bzw. ansatzweise "over-designed".

    Im Allgemeinen bin ich aber sehr begeistert, und verwende die Boost lieber, als so ziemlich jede andere Library die ich kenne. (Die Standard C++ Library zähl' ich mal nicht mit, die verwende ich auch gerne.)

    Aber.
    Wenn hier schon Boost-Bashing betrieben wird, dann wäre es doch sinnvoll, einige konkrete Dinge vorzubringen/zu bekritteln.
    Dann könnte man nämlich auch etwas sinnvoller darauf antworten. z.B. erklären wieso etwas so gemacht wurde, was der Sinn ist, Misverständnisse aufklären etc. Oder auch zustimmen dass es schlecht ist.

    0
Anmelden zum Antworten