diff --git a/src/lib/par/disposition.hpp b/src/lib/par/disposition.hpp index 70319cbc4..d870c8bd4 100644 --- a/src/lib/par/disposition.hpp +++ b/src/lib/par/disposition.hpp @@ -52,14 +52,18 @@ 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 class ParamData - : public TypedEntity + : public TypedEntity { - V val_{}; - Provision* src_{nullptr}; + VAL val_; + Provision* src_; public: + ParamData (VAL initVal) + : val_{std::move (initVal)} + , src_{nullptr} + { } }; diff --git a/src/lib/par/parameter.hpp b/src/lib/par/parameter.hpp index 2ebe47539..cacd25897 100644 --- a/src/lib/par/parameter.hpp +++ b/src/lib/par/parameter.hpp @@ -32,6 +32,8 @@ #include "lib/par/disposition.hpp" #include "lib/polymorphic-value.hpp" +#include + namespace lib { namespace par { @@ -44,6 +46,7 @@ namespace par { } + /** * Descriptor and container to hold a generic parameter. * The value can be fixed or supplied by an automation function. @@ -52,6 +55,7 @@ namespace par { : protected ParamContainer { public: + template class Builder; template @@ -63,30 +67,32 @@ namespace par { /* === Builder API === */ template - static Builder forType(); + static Builder + forType() { return {}; } protected: - - }; - - - class Parameter::Builder - { - public: - Parameter - build() - { - UNIMPLEMENTED ("terminal builder operation: package a disposition into the Parameter"); - } + template + Parameter (IMP* typeTag, ARGS&&... args) + : PolymorphicValue (typeTag, std::forward(args)...) + { } }; template - Parameter::Builder - Parameter::forType() + class Parameter::Builder { - UNIMPLEMENTED ("how to setup the base type configuration? do we need a type parameter in the Builder class?"); - } + VAL initVal_{}; + + public: + Parameter + build() + { + using ImplPackage = ParamData; + ImplPackage* typeTag{nullptr}; + Parameter resParam{typeTag, std::move (initVal_)}; + return resParam; + } + }; template diff --git a/src/lib/polymorphic-value.hpp b/src/lib/polymorphic-value.hpp index d9ff8787f..e3fad2293 100644 --- a/src/lib/polymorphic-value.hpp +++ b/src/lib/polymorphic-value.hpp @@ -516,7 +516,7 @@ namespace lib { static PolymorphicValue build (ARGS&&... args) { - Adapter* type_to_build_in_buffer(0); + IMP* type_to_build_in_buffer; return PolymorphicValue (type_to_build_in_buffer, std::forward(args)...); } diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 5e8132043..6d582230e 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -64126,7 +64126,8 @@ - + + @@ -64805,7 +64806,8 @@ - + + @@ -64821,6 +64823,17 @@ + + + + +

+ ...war mir aber letztlich nicht schlüssig, in welche Richtung meine Abwägung geht; die C++-STDLIB verwendet ja zwei Funktionspointer, von denen einer auf einen generischen Instance-Manager zeigt. Meine eigenen »Freihand-Abwägungen« bezüglich generierter Assembly und Runtime-Overhead weisen aber immer wieder in die Richtung, daß eine VTable effizienter ist, als mehrere Funktionspointer, wobei im Fall von lediglich zwei Pointern vermutlich immer noch nahezu Äquivalenz besteht. Das Problem bei solchen Abwägungen im Kontext von LIbrary-Design ist, daß man die Frage eigentlich nicht empirisch entscheiden kann; Microbenchmarks sind immer nur Momentaufnahmen, und der globale Impact einer solchen Entscheidung ist extrem schwer zu fassen (und aufwendig zu untersuchen) +

+ + + + @@ -64828,6 +64841,13 @@ + + + + + + + @@ -83964,7 +83984,7 @@ - + @@ -83993,6 +84013,16 @@ + + + + + + + + + + @@ -84503,6 +84533,55 @@ + + + + + + + + + +

+ ....diese erscheint heutzutage in mehrfacher Hinsicht als unbeholfen  — wobei allerdings die Wurzeln noch in die Zeit vor C++11 zurückreichen. Im Besonderen gibt es keinen direkt nutzbaren Konstruktor, und auch keine effizienten move-Assignments (copy-and-swap-Idiom). Demzufolge würde bereits eine direkte per-Value-Initialisierung der Basisklasse sofort einen Aufruf des virtuellen-Copy-APIs nach sich ziehen.... +

+ + + + + + + +

+ ...da ich dieses Konstrukt zunehmend für bedeutsam halte, und in viel größerem Umfang zu verwenden gedenke — es könnte sogar das bisherige ref-count-basiderte Memory-Management im high-level-Model ablösen.... +

+ + + + + + + + + + +

+ ....der proctcted-ctor bekommt ein marker-Tag, das definiert ist als IMP* — dadurch wird der Typ IMP kommuniziert und in einen TypeSelector<IMP> verwandelt ... der dann allerdings erneut indirekt an den eigentlichen Arbeits-ctor weitergetgeben wird. Oh (Herr)mann! +

+ + + + + + + + +

+ damit sollte laut Standard der initiale Parameter-Value tatsächlich in-place konstruiert werden, ohne Aufruf des virtuellen copy-support +

+ + +