From bf77e53b4ce27af26c99f631be075c24e8b6cb6d Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Tue, 24 Mar 2026 23:27:43 +0100 Subject: [PATCH] BufferProvider: obvious convenience function ...to emplace some object into the buffer space. I wouldn't expect that to be necessary for the real usage, but it comes in handy for tests, where we often want to place some sentinel value into a buffer. --- src/vault/mem/buffhandle.hpp | 11 ++ tests/vault/out/output-slot-protocol-test.cpp | 6 +- wiki/thinkPad.ichthyo.mm | 104 +++++++++++++++++- 3 files changed, 113 insertions(+), 8 deletions(-) diff --git a/src/vault/mem/buffhandle.hpp b/src/vault/mem/buffhandle.hpp index 9ce4dae1e..4b272ed18 100644 --- a/src/vault/mem/buffhandle.hpp +++ b/src/vault/mem/buffhandle.hpp @@ -168,6 +168,9 @@ namespace mem { template BU& accessAs(); + template + BU& emplace (ARGS&& ...); + Buff* rawStorage() const { @@ -213,6 +216,14 @@ namespace mem { } + /** plant a new object of given type into the buffer storage */ + template + BU& + BuffHandle::emplace (ARGS&& ...args) + { + REQUIRE (sizeof(BU) <= size(), "Buffer too small for object to build."); + return * new(pBuffer_) BU(std::forward (args)...); + } }} // namespace vault::mem diff --git a/tests/vault/out/output-slot-protocol-test.cpp b/tests/vault/out/output-slot-protocol-test.cpp index 8012ae4c7..2afddafc3 100644 --- a/tests/vault/out/output-slot-protocol-test.cpp +++ b/tests/vault/out/output-slot-protocol-test.cpp @@ -75,12 +75,12 @@ namespace test { BuffHandle buff10 = sink1(frameNr); // rendering process calculates content.... - buff00.accessAs() = testData(0,0); + buff00.emplace (testData(0,0)); // while further frames might be processed in parallel BuffHandle buff11 = sink1(frameNr+1); - buff11.accessAs() = testData(1,1); - buff10.accessAs() = testData(1,0); + buff11.emplace (testData(1,1)); + buff10.emplace (testData(1,0)); // Now it's time to emit the output buff11.emit(); diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index d6d9b1b23..3de7b1f7b 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -114262,11 +114262,27 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - + + - - + + + + + + + +

+ KISS und YAGNI +

+

+ Im Moment brauche ich nämlich exakt gar keine Validierung, und sehe schon wieder die gefahr, daß ich mir in Gedanken ein großes Bauwerk baue +

+ + + + @@ -117850,7 +117866,31 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - + + + + + + +

+ ...es paßt nämlich nicht ins Schema: +

+
    +
  • + im Kern ist die DataSink ein SAM-Interface; und dann soll sie's auch wirklich sein +
    • +
  • + das Buffer-Provider-Protokoll sieht da nichts vor und verlangt daß der Client zwingend release() aufrufen muß (habe mich also letztlich dagegen entschieden, daß das BuffHandle »smart« ist — und dann ist es eben auch nicht smart) +
    • +
+

+ Letztlich beruhen alle Konsistenzchecks auf dem prüfen eines Zeitfensters und setzen Mitarbeit durch den Client vorraus; die Interaktion ist als Low-Level-Protokoll charakterisiert, einen Schutz gegen Mißbrauch gibt es nicht. Wenn also der Client release()  aufgerufen hat, und es dann später lustig findet, neue Daten über das BuffHandle in den Buffer zu legen, dann sei es so, und dann sollen sich die User beschweren. +

+ + + + + @@ -137993,7 +138033,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - + @@ -139479,6 +139519,50 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) + + + + + + + + + + + + + + +

+ ...hab zwar jetzt eine Menge über C++ gelernt, und ein schönes neues Macro gebaut, bloß um dann zu merken, daß const-correctness nicht ohne Grund da ist. +

+

+ Trotzdem ärgere ich mich, daß ich schon wieder so lange mit dem Thema verbracht habe +

+ + + + + + + + + + + + + + + + + + + + + + + + @@ -168179,6 +168263,16 @@ std::cout << tmpl.render({"what", "World"}) << s + + + + +

+ Kann sehr nützlich sein, weil man nun in Template-Code den konkreten Subtyp in die Hand bekommen kann. Beispiel in Lumiera: prop-builder.hpp +

+ + +