From ee629b56b7dd2d7fdb50253caf2baf05d9372a77 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Wed, 2 Sep 2026 23:10:07 +0200 Subject: [PATCH] Parameter: resolve `PolymorpicValue` setup MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `PolymorphicValue` incurs some quite confusing requirements due to the clumsy way how the instance handling and copy support must be injected. As pointed out in #1197, with modern C++, this could be much simplified. An overhaul of `PolymorphicValue` seems urgent thus -- in the meanwhile we need to introduce more flexibiltiy with base-class template parameters, so that we can inject the CopySupport interface at usage site of the complete implementation class chain. Furthermore, the size of the VTable is added automatically to the storage requirements in `PolymorphicValue`, so we must subtract it when specifying the payload size by a compile-time expression based on `sizeof(ParamData)` With these tweaks, we can now keep the limit of 4 «slots» (32 bytes) and still reserve 64bit for ID and type flags. --- src/lib/par/disposition.hpp | 12 +++--- src/lib/par/parameter.hpp | 6 +-- tests/lib/par/parameter-test.cpp | 5 --- wiki/thinkPad.ichthyo.mm | 69 +++++++++++++++++++++++++++++--- 4 files changed, 72 insertions(+), 20 deletions(-) diff --git a/src/lib/par/disposition.hpp b/src/lib/par/disposition.hpp index b35e387cd..642d3d6a1 100644 --- a/src/lib/par/disposition.hpp +++ b/src/lib/par/disposition.hpp @@ -64,9 +64,9 @@ namespace par { * with domain and scale, and a value provision. Can be generated through a builder * notation and stored within the Parameter object (as a container). */ - template + template /////////////////////////////////////////////////////TICKET #1197 : the second template argument is quite confusing and became necessary due to the limitations of PolymorphicValue class ParamData - : public TypedEntity + : public TypedEntity { VAL val_; Provision* src_; @@ -87,16 +87,16 @@ namespace par { - template + template void - ParamData::retrieveInto (ValBuff& target) const + ParamData::retrieveInto (ValBuff& target) const { asValue(target) = val_; } - template + template void - ParamData::setValFrom (ValBuff const& newVal) + ParamData::setValFrom (ValBuff const& newVal) { val_ = asValue(newVal); } diff --git a/src/lib/par/parameter.hpp b/src/lib/par/parameter.hpp index 41f28d2cb..ad7fd4b97 100644 --- a/src/lib/par/parameter.hpp +++ b/src/lib/par/parameter.hpp @@ -40,10 +40,10 @@ namespace lib { namespace par { namespace { - static constexpr size_t BUFF_SIZ = sizeof(ParamData); + static constexpr size_t PAYLOAD_SIZ = sizeof(ParamData) - sizeof(void*); ////////////////////////TICKET #1197 : this is a mess! PolymorphicValue adds the ADMIN_OVERHEAD (but our payload has already a VTable) using ParameterImplAPI = Disposition; using CopySupportMarker = polyvalue::CopySupport; - using ParamContainer = PolymorphicValue; + using ParamContainer = PolymorphicValue; } using util::unConst; @@ -100,7 +100,7 @@ namespace par { Parameter build() { - using ImplPackage = ParamData; + using ImplPackage = ParamData; //////////////////////////////////////////TICKET #1197 : remove the necessity to inject the CopySupportMarker ImplPackage* typeTag{nullptr}; Parameter resParam{typeTag, std::move (initVal_)}; return resParam; diff --git a/tests/lib/par/parameter-test.cpp b/tests/lib/par/parameter-test.cpp index 8de7a421e..33b7596a4 100644 --- a/tests/lib/par/parameter-test.cpp +++ b/tests/lib/par/parameter-test.cpp @@ -77,12 +77,7 @@ namespace test{ void simpleUsage() { -SHOW_EXPR(BUFF_SIZ); CHECK (sizeof(Parameter) <= 4 * sizeof(void*)); -SHOW_EXPR(BaseTypeID::value) -SHOW_EXPR(BaseTypeID::value) - ParamData dip(55); -SHOW_EXPR(sizeof(dip)) Parameter par = Parameter::forType().build(); CHECK (0 == par.getVal()); diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index c6a92ede1..d7c97e9c1 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -84071,9 +84071,9 @@ - + + - @@ -84655,9 +84655,10 @@ - + - + + @@ -84669,9 +84670,65 @@

- + + + + + + + + + +

+ ...ich hatte es zwar definiert und im Container-Typ angegeben — aber dann im konkreten API-Aufbau doch nicht eingeschleift (weil es da thematisch ja auch nicht hingehört, Grrrr) +

+ + + + + + + + + + + + + + + +

+ insofern dieses ganze clevere seitwärige Attachment überflüssig ist;  die einzige zwingende Voraussetzung ist, daß wir eine VTable haben +

+ + + + + + + + + + + + + + + + + +

+ weil PolymorphicValue da blindlings seinen ADMIN_OVERHEAD draufschlägt. Das ist ein sekundäres Problem im API-Design — wenn das Marker-API und der »workaround« mit dem Mix-in nicht mehr gebraucht werden, dann fällt auch diese ganze Verwirrung hier weg (die mich jetzt viele Stunden gekostet hat) +

+ + + + + + + + -