Guten Morgen, bei einem Stapelspeicher/Stack/LIFO sind die Verben "push" und "pop" für das Speichern und das zerstörende Auslesen fixe Termini. Gibt es solche fixen Termini auf für Ringpuffer/FIFO? Auf Anhieb finde ich nur "Enqueue" und "Dequeue", aber das liest sich komisch.
Walter T. schrieb: > Gibt es solche fixen Termini auf für Ringpuffer/FIFO? Auf Anhieb finde > ich nur "Enqueue" und "Dequeue", aber das liest sich komisch. Die Begriffe sind OK. Die kommen aus der Queue- (Warteschlangen-) Theorie und ein FIFO ist eine Warteschlange.
Marten Morten schrieb: > Die Begriffe sind OK. Die kommen aus der Queue- (Warteschlangen-) > Theorie und ein FIFO ist eine Warteschlange Nach meinem Gefühl: Read/Write bei Bytes, andere Begriffe nur bei "Objekten" Oder in anderen Worten: Read/Write wenn mehrere Elemente nacheinander zusammen gehören.
Perl hat push und pop für das Ende einer Liste und shift und unshift für den Anfang. Man könnte also push und shift verwenden.
Walter T. schrieb: > Gibt es solche fixen Termini auf für Ringpuffer/FIFO? Wenn ich "FIFO schreiben" und "FIFO lesen" sage, schaut mich keiner schräg an. Jeder weiß dann auch, dass dazu etwas mehr Handling nötig ist, als eine "normale" Speicherzelle/Variable zu beschreiben oder zu lesen.
:
Bearbeitet durch Moderator
Vincent H. schrieb: > Als C++ Nutzer: push_back und pop_back (bzw push_front und pop_front) Mit push_back und pop_back (dann brauchst Du auch back()) wird es ein Stack ;-) Und std::queue hat push() und pop()/front(): https://en.cppreference.com/w/cpp/container/queue
Wilhelm M. schrieb: > Vincent H. schrieb: >> Als C++ Nutzer: push_back und pop_back (bzw push_front und pop_front) > > Mit push_back und pop_back (dann brauchst Du auch back()) wird es ein > Stack ;-) > > Und std::queue hat push() und pop()/front(): > > https://en.cppreference.com/w/cpp/container/queue Und std::list hat push_X/pop_X ;) https://en.cppreference.com/w/cpp/container/list
Vincent H. schrieb: > Wilhelm M. schrieb: >> Vincent H. schrieb: >>> Als C++ Nutzer: push_back und pop_back (bzw push_front und pop_front) >> >> Mit push_back und pop_back (dann brauchst Du auch back()) wird es ein >> Stack ;-) >> >> Und std::queue hat push() und pop()/front(): >> >> https://en.cppreference.com/w/cpp/container/queue > > > Und std::list hat push_X/pop_X ;) > > https://en.cppreference.com/w/cpp/container/list Die Frage war nach einem FIFO. Und das realisiert man in C++ mit einem Adapter statt mit einem Container direkt.
Bei FIFO's werden gerne die Wörter "HEAD" und "TAIL" verwendet. z.B. RemoveHead( &elem ), oder AddTail( *elem )... Gruß T.
Walter T. schrieb: > bei einem Stapelspeicher/Stack/LIFO sind die Verben > "push" und "pop" für das Speichern und das zerstörende > Auslesen fixe Termini. > > Gibt es solche fixen Termini auf für Ringpuffer/FIFO? > Auf Anhieb finde ich nur "Enqueue" und "Dequeue", aber > das liest sich komisch. Naja, sowohl Stack als auch Warteschlange fasse ich als Listen auf; der Unterschied ist nur, an welchem Ende gelesen und geschrieben wird. Zugriffe "am Anfang" (--> Stack) heißen bei mir wie üblich "push" und "pop". "Am Ende anhängen" heisst bei mir ganz simpel "append". Für das zerstörende Lesen vom Ende fehlt mir auch noch das Verb.
Egon D. schrieb: > Naja, sowohl Stack als auch Warteschlange fasse ich als > Listen auf; der Unterschied ist nur, an welchem Ende > gelesen und geschrieben wird. > Stack, Queue, Deque (und auch List) sind ADTs. Nicht jeder Stack ist als Liste implementiert, oft ist der Stack ein generischer Adapter auf einen sequentiellen Container (wie etwa eine verkettete Liste). Oft wird mit (Linked-)List auch die konkrete Implementierung eines sequentiellen Containers gemeint.
Egon D. schrieb: > Naja, sowohl Stack als auch Warteschlange fasse ich als > Listen auf Nur ein sehr dumm implementierter FIFO ist eine Liste. Der Witz eines FIFO ist je gerade, den Overhead einer Liste zu vermeiden. Und: Nur ein sehr dumm implementierter Stack ist eine Liste. Der Witz eines Stack ist nämlich auch gerade, den Overhead einer Liste zu vermeiden. Darüber schon einmal nachgedacht?
Walter T. schrieb: > Gibt es solche fixen Termini auf für Ringpuffer/FIFO? Eigentlich nicht, denn ein FIFO ist eigentlich dafür gedacht, im stillen irgendwelche Zwischenspeicherungen zu erledigen, ohne dediziert für die aufrufenden Programme in Erscheinung zu treten. Also sollte es bei einem Fifi in Schreibrichtung nur 2 Aufrufe geben: bool IstNochPlatzFrei() und irgendwas SchreibeMeinDing(irgendwas MeinDing) und in Leserichtung: bool GibtEsIrgendwasZuLesen() irgendwas GibMirWasDuHast() Wozu sollte es da solche Begriffe wie push und pop geben? Es ist ja kein LiFo. W.S.
Wilhelm M. schrieb: > Nicht jeder Stack ist als Liste implementiert, > [...] Nicht einmal jede Liste ist als Liste implementiert. Zu meinem eigentlichen Kernpunkt, dass mir für das zerstörende Lesen vom Ende einer Deque auch das passende schöne Verb fehlt, hast Du leider nix gesagt.
Egon D. schrieb: > Wilhelm M. schrieb: > >> Nicht jeder Stack ist als Liste implementiert, >> [...] > > Nicht einmal jede Liste ist als Liste implementiert. > > Zu meinem eigentlichen Kernpunkt, dass mir für das > zerstörende Lesen vom Ende einer Deque auch das > passende schöne Verb fehlt, hast Du leider nix > gesagt. Ich halte mich an die C++ Nomenklatur.
W.S. schrieb: > Walter T. schrieb: >> Gibt es solche fixen Termini auf für Ringpuffer/FIFO? > > Eigentlich nicht, denn ein FIFO ist eigentlich dafür > gedacht, im stillen irgendwelche Zwischenspeicherungen > zu erledigen, Ja. > ohne dediziert für die aufrufenden Programme in > Erscheinung zu treten. Nö. > Also sollte es bei einem Fifi in Schreibrichtung nur > 2 Aufrufe geben: > bool IstNochPlatzFrei() > und > irgendwas SchreibeMeinDing(irgendwas MeinDing) > > und in Leserichtung: > bool GibtEsIrgendwasZuLesen() > irgendwas GibMirWasDuHast() Auch nicht. Konkretes Beispiel: Mein in Tcl implementiertes Linux- Installationstool behandelt reale Pakete (die direkt von anderen Paketen abhängen) und virtuelle Pakete (deren Behandlung deutlich komplizierter ist) unter- schiedlich: Reale Pakete werden mit "push" auf den "Stapel" gelegt und mit "pop" gelesen. Die Behandlung virtueller Pakete wird solange verzögert, bis alle realen Pakete bearbeitet wurden, was ganz einfach dadurch erreicht wird, dass die virtuellen Pakete mittels "append" hinten an die "Warteschlange" angefügt werden. Unnötig zu erwähnen, dass der "Stapel" und die "Warteschlange" mittels ein und derselben "Deque" implementiert sind. > Wozu sollte es da solche Begriffe wie push und pop > geben? Es ist ja kein LiFo. Weil diese strikte Unterscheidung sinnlos ist. Eine "Deque" kann als Stapel oder als Warteschlange verwendet werden , und zwar auch dieselbe Deque im selben Programm mal so und mal so.
Wilhelm M. schrieb: > Egon D. schrieb: >> Wilhelm M. schrieb: >> >>> Nicht jeder Stack ist als Liste implementiert, >>> [...] >> >> Nicht einmal jede Liste ist als Liste implementiert. >> >> Zu meinem eigentlichen Kernpunkt, dass mir für das >> zerstörende Lesen vom Ende einer Deque auch das >> passende schöne Verb fehlt, hast Du leider nix >> gesagt. > > Ich halte mich an die C++ Nomenklatur. Und ich bin Tcl-sozialisiert.
THaala schrieb: > Bei FIFO's werden gerne die Wörter "HEAD" und "TAIL" verwendet. > > z.B. RemoveHead( &elem ), > oder AddTail( *elem )... Ich stelle mir diese Operationen gerade beim Tierarzt vor…
W.S. schrieb: > irgendwas SchreibeMeinDing(irgendwas MeinDing) > > und in Und SchreibeMeinDing ist jetzt besser als push oder write weil? W.S. schrieb: > ohne dediziert für die aufrufenden Programme in Erscheinung zu treten. Eine unsichtbare Komponente kann nicht genutzt werden und ist daher sinnlos. Irgend ein API muss es haben.
W.S. schrieb: > Walter T. schrieb: >> Gibt es solche fixen Termini auf für Ringpuffer/FIFO? > > Eigentlich nicht, denn ein FIFO ist eigentlich dafür gedacht, im stillen > irgendwelche Zwischenspeicherungen zu erledigen, ohne dediziert für die > aufrufenden Programme in Erscheinung zu treten. Was fürn Quatsch mit Souce! Das mag vllt bei so einigen embeddet UART Lösungen so sein wo eine FIFO fest in den Treiber genagelt ist für unblockierendes IRQ senden. Da haste dann nur dein putc/puts und gut. Aber sobald man mal ordentlich programmiert sind FIFOs auch dediziert vorhanden. zB in Form einer OS FIFO um zwischen mehreren Tasks Daten/Aufgaben zu verteilen. Da kommen wir jetzt wieder zum Thema, FreeRTOS hat da ja auch Namen für, die hab ich dann einfach übernommen: https://www.freertos.org/a00018.html -SendToBack -SendToFront -Receive (zerstörendes lesen) -Peek (lesen ohne zerstören)
c-hater schrieb: > Nur ein sehr dumm implementierter FIFO ist eine Liste. Der Witz eines > FIFO ist je gerade, den Overhead einer Liste zu vermeiden. Ich denke, dass du gerade nur zur Hälfte Recht hast. Natürlich ist auch ein FIFO oder ein Stack eine Liste, allerdings eine sehr simple. Je mehr Methoden du für diese Liste hast/definierst, um so größer wird natürlich der Overhead. Ob man also ein FIFO, mit dem man "alles Mögliche" anstellen kann - also hinten/vorne, zerstörungsfrei oder nicht, lesen und was sonst noch - so noch nennen wird, ist eine andere Frage...für mich zumindest fraglich... Gruß Rainer
Rainer V. schrieb: > Natürlich ist auch > ein FIFO oder ein Stack eine Liste, allerdings eine sehr simple. Das siehst du falsch. Es sind eben keine Listen, weil sie nur spezielle Zugriffsmuster implementieren und nicht das allgemeine Listeninterface. Und der Sinn darin, eben nur diese speziellen Zugriffsmuster abzubilden, ist, dass die Beschränkung darauf das Konstrukt (ggf. um ein Vielfaches!) effizienter machen kann. Der Gewinn entsteht dabei nicht dadurch, dass Zugriffsmethoden entfallen, sondern dadurch, dass die interne Verwaltung des Speichers effizienter umgesetzt werden kann. Das entfallen der Listen-Zugriffsmethoden ist dann nur die FOLGE. Sie lassen sich mit der auf Effizienz für die speziellen Zugriffsmuster getrimmten internen Datenverwaltung schlicht nicht realisieren. Genau, weil das alles so ist, wie es ist, ist es auch dumm, einer generischen Liste die passenden Zugriffsmethoden für FIFO oder Stack zu verpassen, den Rest zu verstecken und ansonsten alles beizubehalten. Das macht nichts effizienter, beschränkt nur unnütz die Möglichkeiten. Da bleibt man dann besser einfach bei der Liste und setzt das Zugriffsmuster mit mit deren Methoden um.
Egon D. schrieb: > "Am Ende anhängen" Da gehts schon los: Was ist das "Ende", wo ist "vorne", von welchem Ende aus muss mans betrachten damit das Sinn ergibt? Für mich hat eine Queue konzeptionell erstmal nur "rein" und "raus". Ich persönlich favorisiere put() und get() für die Grundfunktionen der Queue.
Bernd K. schrieb: > Egon D. schrieb: >> "Am Ende anhängen" > > Da gehts schon los: Was ist das "Ende", wo ist > "vorne", von welchem Ende aus muss mans betrachten > damit das Sinn ergibt? Das ist egal. Entscheidend ist nur: "Push" und "Pop" wirken auf dasselbe Ende, "Append" und "Pop" aber auf verschiedene. Welches Ende Du Dir "vorn" oder "hinten" vorstellst, ist völlig egal. Womit auch offenkundig wird, dass ich die ganze Zeit ein Brett vor dem Kopf hatte: Man braucht überhaupt keinen vierten Begriff. > Für mich hat eine Queue konzeptionell erstmal nur > "rein" und "raus". Ich persönlich favorisiere put() > und get() für die Grundfunktionen der Queue. Das verstehe ich. Auf der anderen Seite bin ich aber ein Freund der "verständigen Abstraktion": Wenn sich Dinge konzeptionell dermaßen ähnlich sind wie ein Stack, eine Warteschlange und eine Deque, dann bevorzuge ich es aus Gründen des erreichten Lebensalters und der Faulheit, mir nur EIN Ding merken zu müssen und die anderen daraus ableiten zu können. Eine Deque mit den Operationen "push", "pop" und "append" leistet für mich das Gewünschte. Aber natürlich muss niemand meiner Sichtweise folgen.
c-hater schrieb: > Rainer V. schrieb: > >> Natürlich ist auch >> ein FIFO oder ein Stack eine Liste, allerdings >> eine sehr simple. > > Das siehst du falsch. Es sind eben keine Listen, > weil sie nur spezielle Zugriffsmuster implementieren > und nicht das allgemeine Listeninterface. Das siehst Du falsch. Ein dreibeiniger Hund oder ein Auto ohne Dach ist auch ein Hund bzw. ein Auto, obwohl sie nicht das allgemeine Hunde- bzw. Auto-Interface implementieren. Die Welt richtet sich glücklicherweise nicht nach von Dir frei erfundenen Forderungen. > Und der Sinn darin, eben nur diese speziellen > Zugriffsmuster abzubilden, ist, dass die Beschränkung > darauf das Konstrukt (ggf. um ein Vielfaches!) > effizienter machen kann. Unsinn. Der Sinn, das Zugriffsmuster eines Stacks abzubilden, liegt darin, dass mein Algorithmus auf einem Stack basiert.
Egon D. schrieb: > Das siehst Du falsch. Ein dreibeiniger Hund oder ein > Auto ohne Dach ist auch ein Hund bzw. ein Auto, obwohl > sie nicht das allgemeine Hunde- bzw. Auto-Interface > implementieren. Sorry, Quark, wie immer...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.