diff --git a/src/lib/iter-source.hpp b/src/lib/iter-source.hpp index 9a817e72a..2444d8aa1 100644 --- a/src/lib/iter-source.hpp +++ b/src/lib/iter-source.hpp @@ -143,14 +143,7 @@ namespace lib { : IterAdapter { using _I = IterAdapter; - using _I::IterAdapter; - iterator() =default; /////////////////////////////////////TICKET #1117 : why the hell do we need to declare all those ctor variants explicitly? I was under the impression ctor calls worked correct up to now without all this... - iterator(iterator&&) =default; - iterator(iterator const&) =default; - iterator(iterator& r) : iterator((iterator const&)r) { } - iterator& operator= (iterator &&) =default; - iterator& operator= (iterator const&) =default; operator string() const {return _I::source()? string(*_I::source()) : "⟂"; } }; diff --git a/src/lib/iter-tree-explorer.hpp b/src/lib/iter-tree-explorer.hpp index 9d6d9e585..5339487ce 100644 --- a/src/lib/iter-tree-explorer.hpp +++ b/src/lib/iter-tree-explorer.hpp @@ -447,16 +447,17 @@ namespace lib { * call, where some "expansion layer" consumes the current element and replaces it by an expanded * series of new elements. Other layers might need to sync to this operation, and thus it is passed * down the chain. For that reason, we need a dedicated BaseAdapter to adsorb such chained calls. + * @remark when building the TreeExplorer, the to-be-wrapped source is fed down into its place + * within BaseAdapter. For that reason, we need to lift the copy ctors of the base. + * Just inheriting the base class ctors won't do that, at least not in C++14. */ template struct BaseAdapter : SRC { - using SRC::SRC; - BaseAdapter(SRC const& src) : SRC(src) { } ////////////////////////TODO why the hell do we need to redeclare all those ctor variants???? - BaseAdapter(SRC && src) : SRC(src) { } - BaseAdapter(SRC & src) : SRC(src) { } BaseAdapter() = default; + BaseAdapter(SRC const& src) : SRC(src) { } + BaseAdapter(SRC && src) : SRC(src) { } void expandChildren() { } }; @@ -781,10 +782,6 @@ namespace lib { /** pass-through ctor */ using SRC::SRC; - TreeExplorer(SRC const& src) : SRC(src) { } ////////////////////////TODO why the hell do we need to redeclare all those ctor variants???? why isn't copy initialisation propagated from the base ctors? - TreeExplorer(SRC && src) : SRC(src) { } - TreeExplorer(SRC & src) : SRC(src) { } - TreeExplorer() = default; diff --git a/tests/library/iter-tree-explorer-test.cpp b/tests/library/iter-tree-explorer-test.cpp index 70047c815..c67d906a9 100644 --- a/tests/library/iter-tree-explorer-test.cpp +++ b/tests/library/iter-tree-explorer-test.cpp @@ -751,7 +751,7 @@ namespace test{ exploreIter = treeExplore(sequence) .filter([](int i){ return i>30; }) - .expand([](int i){ return CountDown{i-10, 20}; }) + .expand([](uint i){ return CountDown{i-10, 20}; }) .transform([](uint u) -> char { return '@'+u-20; }) .asIterSource(); diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 1bc8dfbcf..2c95fb1f9 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -6035,18 +6035,147 @@ - - - - + + + + + + + + + + + +

+ ...da gibt es eine explizite Ausnahme-Regel. +

+

+ Die Copy-Konstruktoren werden aus der Kandidaten-Menge entfernt. +

+

+ +

+

+ Grund ist, daß die default-Initialisierung der Member-Felder noch nicht hinrechend geklärt war. +

+

+ C++17 holt das nach +

+ + + - - + + + + + + +

+ ...dort wird einfach on-demand in der Basisklasse nachgeschaut. +

+

+ Wenn dabei ein Basis-Copy-Ctor gezogen wird, dann wird eben default-Init für die Felder im abgeleiteten Objekt gemacht. +

+

+ Es gibt dann eine neue, explizite Regel, die verhindert, daß zufällig ein aus der Basis geerbter Ctor +

+

+ die Signatur eines Copy-ctors überdeckt +

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

+ Allerdings genügt es, dies an einer Stelle in der Kette zu ergänzen +

+ + + + + + + + +

+ ...und zwar genau dort, wo erstmals ein Basis-Objekt akzeptiert wird. +

+

+ Das ist bei uns im BaseAdapter, also der ersten Ebene über dem zu initialisierenden Basis-Objekt. +

+

+ Alle anderen Layer darüber reichen dann korrekt mit dem geerbten Ctor diese Initialisierung nach Unten. +

+ + + + + + + + + + +

+ übrigens ist es im IterSource<T>::iterator nicht  notwendig +

+ + + + + + + + +

+ ...das war nur ein unnötiger Fix nach dem Gießkannen-Prinzip. +

+

+ +

+

+ Denn dieser Iterator soll niemals mit einem Basis-Objekt initialisiert werden, +

+

+ sondern stets von der IterSource-Builder-Funktion konstruiert. +

+

+ Und wenn man selber keinen Ctor in eine Klasse schreibt, sondern nur ctor-erbt, +

+

+ dann werden auch die Copy-Konstruktoren korrekt automatisch generiert. +

+ + + + + + + + - - + + + + + + + + + + + + @@ -6364,7 +6493,7 @@ - +