STL-template für FIFO?



  • It0101 schrieb:

    knivil schrieb:

    Üblicherweise der, der sie erzeugt hat. Und das ist bei mir nicht anders.

    Diese Zeile sagt was anderes:

    for ( p = Buffer; p != pe; delete *p++ );
    

    Diese Zeile löscht das Element, weil ich sonst vom Eigentümer verlangen müsste, den Buffer mit "get" komplett zu entleeren.

    Aber damit ist nicht mehr klar, wer der Eigentümer ist.

    It0101 schrieb:

    Hat schlicht und ergreifend praktische Gründe.

    Praktisch ist es eben genau nicht. Kann man sehr leicht aufzeigen:

    // in irgendeinem Block
    {
      RingBufferFIFO<int> buffer(20);
    
      // ... irgendwo im nirgendwo passt der Programmierer nicht richtig auf,
      // da er sich nicht mehr recht erinnert, dass RingBufferFIFO jeglichem
      // Eigentümer Standard widerspricht.
      int agreatvalue = 256;
      buffer.Put(&agreatvalue);
    
      // ... viel später, aber agreatvalue ist noch im Puffer.
    } // <- BAMMMMM; BUMMM; WELTUNTERGANG ... naja nicht so extrem, aber eben nicht praktisch.
    

    Grüssli



  • Dravere schrieb:

    aber eben nicht praktisch

    gut, dass du das noch dazu schreibst 😃



  • Wie wäre denn eure Vorgehensweise mit den Eigentümerrechten speziell für diese Komponente?

    Ich lass mich ja gern belehren...



  • It0101 schrieb:

    Wie wäre denn eure Vorgehensweise mit den Eigentümerrechten speziell für diese Komponente?

    So wie immer: Wer die Ressourcen anfordert, der gibt sie auch wieder frei.

    Schreib am besten den RingBufferFIFO so um, dass er nicht zwingt, dass Zeiger gespeichert werden. Wenn der Programmierer Zeiger Speichern möchte, kann er dies angeben: RingBufferFIFO<int*> . Dann weiss er aber auch, dass er dafür verantwortlich ist, den Speicher wieder freizugeben. Er ist dann sogar in der Lage, allenfalls einen shared_ptr zu verwenden, wenn er dies möchte und als sinnvoll erachtet.

    Grüssli



  • Ok, dann werd ich das so machen. Das klingt vernünftig 🙂



  • Ich hab das bei mir so geregelt das ich als Template Parameter noch eine Klasse mitnehme die ebenfalls Template ist und eine static delete Funktion hat, die rufe ich beim Entfernen eines Elements auf.



  • Xebov schrieb:

    Ich hab das bei mir so geregelt das ich als Template Parameter noch eine Klasse mitnehme die ebenfalls Template ist und eine static delete Funktion hat, die rufe ich beim Entfernen eines Elements auf.

    Das ist natürlich auch eine Möglichkeit, geht allerdings eher in Richtung Smart-Pointer und Destruction-Policy. Kommt halt drauf an, ob vorrangig Zeiger auf dynamisch angelegte Objekte gespeichert werden. Man sollte aber dran denken, dass der Heap einen Geschwindigkeits- und Speicher-Overhead mit sich bringt, der besonders für kleine Objekte lästig sein kann. Von daher kann es in dieser Hinsicht effizienter sein, nur Speicher für den Ringpuffer anzufordern und die Objekte da reinzukonstruieren.

    Für maximale Performance könnte man auf dem Stack arbeiten. Dabei rate ich zu std::tr1::array , das hat im Release-Modus keinen Overhead gegenüber einem C-Array, aber im Debug-Modus wertvolle Laufzeitprüfungen. Das Containertemplate könnte zum Beispiel so aussehen:

    template <typename T, size_t Size>
    class RingBufferQueue
    {
        public:
            // ...
        private:
            std::tr1::array<T, Size> MyBuffer;
    };
    

Anmelden zum Antworten