benn/lumiera_
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Library: further test and documentation of tuple-zipping

Browse source
This commit is contained in:
Fischlurch 2024-11-26 17:35:05 +01:00
parent 252c735b7b
commit b6ade2c0cf
8 changed files with 281 additions and 214 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
src/lib/diff/gen-node.hpp
View file

@ -662,7 +662,7 @@ namespace diff{
struct GenNode::ScopeExplorerIterator
: IterStateWrapper<const GenNode, ScopeExplorer>
{
using IterStateWrapper<const GenNode, ScopeExplorer>::IterStateWrapper;
using IterStateWrapper::IterStateWrapper;
size_t level() const { return unConst(this)->stateCore().depth(); }
};

113
src/lib/iter-adapter.hpp
View file

@ -3,6 +3,7 @@
Copyright (C)
2009, Hermann Vosseler <Ichthyostega@web.de>
2017,2024, Hermann Vosseler <Ichthyostega@web.de>
  **Lumiera** is free software; you can redistribute it and/or modify it
  under the terms of the GNU General Public License as published by the
@ -24,8 +25,8 @@
** - the IterAdapter retains an active callback connection to the
** controlling container, thus allowing arbitrary complex behaviour.
** - the IterStateWrapper uses a variation of that approach, where the
** representation of the current state is embedded as an state value
** element right into the iterator instance.
** representation of the current state is embedded as a *State Core*
** value element right into the iterator instance.
** - very similar is IterableDecorator, but this time directly as
** decorator to inherit from the »state core«, and without checks.
** - the RangeIter allows just to expose a range of elements defined
@ -44,7 +45,7 @@
** references to pre-existing storage locations (not temporaries).
**
** There are many further ways of building a Lumiera Forward Iterator.
** For example, lib::IterSource exposes a "iterable" source of data elements,
** For example, lib::IterSource exposes an "iterable" source of data elements,
** while hiding the actual container or generator implementation behind a
** VTable call. Furthermore, complex processing chains with recursive
** expansion can be built with the \ref IterExporer builder function.
@ -59,8 +60,8 @@
** # Lumiera Forward Iterator concept
**
** Similar to the STL, instead of using a common "Iterator" base class,
** we rather define a common set of functions and behaviour which can
** be expected from any such iterator. These rules are similar to STL's
** we rather define a common set of functions and behaviour which can be
** expected from any such iterator. These rules are similar to STL's
** "forward iterator", with the addition of an bool check to detect
** iteration end. The latter is inspired by the \c hasNext() function
** found in many current languages supporting iterators. However, by
@ -68,25 +69,28 @@
** support the various extended iterator concepts from STL and boost
** (random access iterators, output iterators, arithmetics, difference
** between iterators and the like). According to this concept,
** _an iterator is a promise for pulling values,_
** _an iterator is a promise for pulling values once,_
** and nothing beyond that.
**
** - Any Lumiera forward iterator can be in a "exhausted" (invalid) state,
** which can be checked by the bool conversion. Especially, any instance
** Notably,
** - any Lumiera forward iterator can be in a "exhausted" (invalid) state,
** which can be checked by the bool conversion. Especially, an instance
** created by the default ctor is always fixed to that state. This
** state is final and can't be reset, meaning that any iterator is
** a disposable one-way-off object.
** state is final and can not be reset, meaning that any iterator
** is a disposable one-way-off object.
** - iterators are copyable and equality comparable
** - when an iterator is _not_ in the exhausted state, it may be
** _dereferenced_ to yield the "current" value.
** _dereferenced_ to yield the _current value_.
** - usually, the _current value_ is exposed by-ref (but by-val is possible)
** - moreover, iterators may be incremented until exhaustion.
**
** Conceptually, a Lumiera Iterator represents a lazy stream of calculations
** rather than a target value considered to be »within« a container. And while
** the result is deliberately _always exposed as a reference,_ to keep the
** door open for special-case manipulations, for the typical usage it is
** _discouraged_ to assume anything about the source, beyond the limited
** access to some transient state as exposed during active iteration.
** the result is in may cases deliberately _exposed as a reference,_ in order
** to keep the door open for special-case manipulations, for the typical usage
** it is _discouraged_ to assume anything about the source, beyond the limited
** access to some transient state as exposed during active iteration. Together,
** these rules enable a _loose coupling_ to the source of data.
**
** @see iter-adapter-test.cpp
** @see itertools.hpp
@ -106,6 +110,13 @@
#include <iterator>
namespace util { // see lib/util.hpp
template<class OBJ>
OBJ* unConst (const OBJ*);
template<class OBJ>
OBJ& unConst (OBJ const&);
}
namespace lib {
@ -140,6 +151,11 @@ namespace lib {
/** type binding helper: an iterato's actual result type */
template<class IT>
using Yield = decltype(std::declval<IT>().operator*());
/** the _result type_ yielded by a »state core« */
template<class COR>
using CoreYield = decltype(std::declval<COR>().yield());
}
@ -328,20 +344,22 @@ namespace lib {
/**
* Another Lumiera Forward Iterator building block, based on incorporating a state type
* right into the iterator. Contrast this to IterAdapter, which refers to a managing
* container behind the scenes. Here, all of the state is assumed to live in the
* custom type embedded into this iterator, accessed and manipulated through
* as »*State Core*«, right into the iterator. Contrast this to IterAdapter, which refers to
* a managing container behind the scenes. To the contrary, here all of the state is assumed
* to live in the custom type embedded into this iterator, accessed and manipulated through
* a dedicated _iteration control API_ exposed as member functions.
*
* \par Assumptions when building iterators based on IterStateWrapper
* There is a custom state representation type ST.
* - default constructible
* - this default state represents the _bottom_ (invalid) state.
* - copyable, because iterators are passed by value
* # Requirements for a »State Core«
* When building iterators with the help of IterStateWrapper or \ref IterableAdapter,
* it is assumed that the adapted _state core_ type represents a process of state evolution,
* which reaches a well defined end state eventually, but this end state is also the _bottom_
* - the core is default constructible
* - this default state represents the _bottom_ (final, invalid) state.
* - copyable, because iterators are passed by value; ideally also assignable
* - this type needs to provide an *iteration control API* with the following operations
* -# \c checkPoint establishes if the given state element represents a valid state
* -# \c checkPoint establishes if the given state element represents a valid active state
* -# \c iterNext evolves this state by one step (sideeffect)
* -# \c yield realises the given state, yielding an element of result type `T&`
* -# \c yield realises the given state, yielding an element of _result type_ \a T
* @tparam T nominal result type (maybe const, but without reference).
* The resulting iterator will yield a reference to this type T
* @tparam ST type of the »state core«, defaults to T.
@ -352,7 +370,7 @@ namespace lib {
* @see iter-explorer-test.hpp
* @see iter-adaptor-test.cpp
*/
template<typename T, class ST =T>
template<typename T, class ST>
class IterStateWrapper
{
ST core_;
@ -481,7 +499,7 @@ namespace lib {
IT&
srcIter() const
{
return unConst(*this);
return util::unConst(*this);
}
public:
@ -526,7 +544,7 @@ namespace lib {
COR&
_rawCore() const
{
return unConst(*this);
return util::unConst(*this);
}
void
@ -626,26 +644,29 @@ namespace lib {
/**
* Decorator-Adapter to make a »state core« iterable as Lumiera Forward Iterator.
* Decorator-Adapter to make a »*State Core*« iterable as Lumiera Forward Iterator.
* This is a fundamental (and low-level) building block and works essentially the
* same as IterStateWrapper — with the significant difference however that the
* _Core is mixed in by inheritance_ and thus its full interface remains publicly
* accessible. Another notable difference is that this adapter deliberately
* *performs no sanity-checks*. This can be dangerous, but allows to use this
* setup even in performance critical code.
* @warning be sure to understand the consequences of using ´core.yield()´ without
* checks; it might be a good idea to build safety checks into the Core
* API functions instead, or to wrap the Core into \ref CheckedCore.
* @warning be sure to understand the consequences of _using_ ´core.yield()´ without
* checks; an iterator built this way _must be checked_ before each use, unless
* it is guaranteed to be valid (by contextual knowledge). It might be a good idea
* to build some safety checks into the Core API functions instead, maybe even just
* as assertions, or to wrap the Core into \ref CheckedCore for most usages.
* @tparam T nominal result type (maybe const, but without reference).
* @tparam COR type of the »state core«. The resulting iterator will _mix-in_
* this type, and thus inherit properties like copy, move, compare, VTable, POD.
* @tparam COR type of the »state core«. The resulting iterator will _mix-in_ this type,
* and thus inherit properties like copy, move, compare, VTable, „POD-ness“.
* The COR must implement the following _iteration control API:_
* -# `checkPoint` establishes if the given state element represents a valid state
* -# ´iterNext` evolves this state by one step (sideeffect)
* -# `yield` realises the given state, exposing a result of type `T&`
* Furthermore, COR must be default-constructible in _disabled_ state
* @note the resulting iterator will attempt to yield a reference to type \a T when possible;
* but when the wrapped `COR::yield()` produces a value, this is passed and also
* #operator-> is then disabled, to prevent taking the adress of the value (temporary)
* but when the wrapped `COR::yield()` produces a value, this is passed as such, moreover
* #operator-> becomes disabled then, to prevent taking the address of the (temporary) value!
* @see IterExplorer a pipeline builder framework on top of IterableDecorator
* @see iter-explorer-test.hpp
* @see iter-adaptor-test.cpp
@ -666,11 +687,7 @@ namespace lib {
}
public:
// typedef T* pointer;
// typedef T& reference;
// typedef T value_type;
/////////////////////////////////////////////////////////////////////////////OOO new YieldRes code
using CoreYield = decltype(std::declval<COR>().yield());
using CoreYield = iter::CoreYield<COR>;
using _CommonT = meta::CommonResultYield<T&, CoreYield>;
using YieldRes = typename _CommonT::ResType;
using value_type = typename _CommonT::value_type;
@ -700,19 +717,16 @@ namespace lib {
explicit operator bool() const { return isValid(); }
YieldRes
// reference
operator*() const
{
return _core().yield(); // core interface: yield
return _core().yield(); // core interface: yield
}
// lib::meta::enable_if_c<_CommonT::isRef,
// pointer >
pointer
operator->() const
{
if constexpr (_CommonT::isRef)
return & _core().yield(); // core interface: yield
return & _core().yield(); // core interface: yield
else
static_assert (_CommonT::isRef,
"can not provide operator-> "
@ -722,14 +736,14 @@ namespace lib {
IterableDecorator&
operator++()
{
_core().iterNext(); // core interface: iterNext
_core().iterNext(); // core interface: iterNext
return *this;
}
bool
isValid () const
{
return _core().checkPoint(); // core interface: checkPoint
return _core().checkPoint(); // core interface: checkPoint
}
bool
@ -774,7 +788,6 @@ namespace lib {
* elements of an embedded STL container, without controlling
* the details of the iteration (as is possible using the
* more generic IterAdapter).
*
* @note
* - when IT is just a pointer, we use the pointee as value type
* - but when IT is a class, we expect the usual STL style nested typedefs
@ -979,7 +992,7 @@ namespace lib {
/// Supporting equality comparisons...
bool operator!= (NumIter const& o) const { return not operator==(o); }
bool operator== (NumIter const& o) const { return (empty() and o.empty()) // empty iters must be equal (Lumiera iter requirement)
bool operator== (NumIter const& o) const { return (empty() and o.empty()) // empty iters must be equal (Lumiera iter requirement)
or (i_ == o.i_ and e_ == o.e_); }
private:

33
src/lib/iter-explorer.hpp
View file

@ -3,6 +3,7 @@
Copyright (C)
2017, Hermann Vosseler <Ichthyostega@web.de>
2024, Hermann Vosseler <Ichthyostega@web.de>
  **Lumiera** is free software; you can redistribute it and/or modify it
  under the terms of the GNU General Public License as published by the
@ -259,10 +260,6 @@ namespace lib {
{ };
/** the _result type_ yielded by a »state core« */
template<class COR>
using CoreYield = decltype(std::declval<COR>().yield());
/**
* @internal Type-selector template to adapt for IterExplorer:
@ -277,7 +274,7 @@ namespace lib {
struct _DecoratorTraits<SRC, enable_if<is_StateCore<SRC>>>
{
using SrcRaw = typename lib::meta::Strip<SRC>::Type;
using SrcVal = typename meta::RefTraits<CoreYield<SrcRaw>>::Value;
using SrcVal = typename meta::RefTraits<iter::CoreYield<SrcRaw>>::Value;
using SrcIter = lib::IterableDecorator<SrcVal, lib::CheckedCore<SrcRaw>>;
};
@ -1599,19 +1596,21 @@ namespace lib {
/* ==== Builder functions ==== */
/** preconfigure this IterExplorer to allow for _"expansion of children"_.
* The resulting iterator exposes an `expandChildren()` function, which consumes
* the current head element of this iterator and feeds it through the
* _expansion functor_, which was provided to this builder function here.
* The _expansion functor_ is expected to yield a sequence of "child" elements,
* which will be integrated into the overall result sequence instead of the
* consumed source element. Thus, repeatedly invoking `expand()` until exhaustion
* generates a _depth-first evaluation_, since every child will be expanded until
* reaching the leaf nodes of a tree like structure.
/** preconfigure this IterExplorer to allow for _»expansion of children«_.
* The resulting iterator exposes an `expandChildren()` function, which must be
* invoked explicitly and consumes then the current head element of this iterator
* and feeds it through the _expansion functor_, which was provided to this builder
* function here. This _expansion functor_ is expected to yield a compatible sequence
* of "child" elements, which will be integrated into the overall result sequence
* instead of the consumed source element. Thus, repeatedly invoking `expand()`
* until exhaustion generates a _depth-first evaluation_, since every child
* will be expanded until reaching the leaf nodes of a tree like structure.
* The result-type of the compound will be chosen appropriately
* (which may imply to return by-value instead of by-reference)
*
* @param expandFunctor a "function-like" entity to perform the actual "expansion".
* There are two distinct usage patterns, as determined by the signature
* of the provided function or functor:
* of the provided callable, function or functor:
* - _"monad style"_: the functor takes a _value_ from the sequence and
* produces a new sequence, iterator or collection of compatible values
* - _"opaque state manipulation"_: the functor accepts the concrete source
@ -1623,6 +1622,10 @@ namespace lib {
* new "child state core" may likewise collaborate with that original
* data source or state core behind the scenes; the latter is guaranteed
* to exist during the whole lifetime of this IterExplorer.
* @warning be cautions when relying on stored references into the wrapped state core,
* because the IterExplorer pipeline as a whole is meant to be movable; either
* take those references only after the pipeline is »engaged« and placed at its
* final storage location, or ensure a way to „refresh“ this information on move.
* @note there is limited support for generic lambdas, but only for the second case.
* The reason is, we can not "probe" a template or generic lambda for possible
* argument and result types. Thus, if you provide a generic lambda, IterExplorer

10
src/lib/iter-zip.hpp
View file

@ -13,6 +13,11 @@
/** @file iter-zip.hpp
** Iterator builder to combine several iterables into a tuple sequence.
** Adaptation is based on the capabilities of IterExplorer, and the result
** will again be a »Lumiera Forward Iterator« and an IterExplorer pipeline builder.
** Depending on the source sequences, references may be exposed. Moreover, a variant
** \ref izip() is provided where the result tuple is prefixed with a counter sequence,
** allowing to perform _iterator with counter_ style evaluations.
**
** @see IterZip_test
** @see iter-explorer.hpp
@ -32,7 +37,6 @@
namespace lib {
namespace iter {
/** construction-helper: apply IterExplorer builder packaged tuple */
@ -43,6 +47,10 @@ namespace lib {
return std::make_tuple (lib::explore (std::forward<ITS> (iters)) ...);
}
/**
* Building block for a tupeled-iterator.
* exposes the iterator API lifted to the product type (tuple).
*/
template<class ITUP>
class ProductCore
{

15
src/lib/meta/value-type-binding.hpp
View file

@ -2,7 +2,7 @@
VALUE-TYPE-BINDING.hpp - control type variations for custom containers
Copyright (C)
2010, Hermann Vosseler <Ichthyostega@web.de>
2010,2024 Hermann Vosseler <Ichthyostega@web.de>
  **Lumiera** is free software; you can redistribute it and/or modify it
  under the terms of the GNU General Public License as published by the
@ -13,7 +13,7 @@
/** @file value-type-binding.hpp
** Type re-binding helper template for custom containers and adapters.
** This header defines a trait template which is used by the Iterator
** This header defines trait templates which are used by the Iterator
** adapters and similar custom containers to figure out the value-,
** pointer- and reference types when wrapping iterators or containers.
**
@ -38,6 +38,11 @@
** treatment, an explicit specialisation to this rebinding trait may be
** injected alongside with the definition of the payload type.
**
** The CommonResultYield type rebinding helper allows to reconcile several
** essentially compatible result types; it is used in iterator pipelines,
** especially for the case of _child expansion,_ where some additional
** sub-sequences are to be integrated into a main sequence.
**
** @see ValueTypeBinding_test
** @see iter-adapter.hpp
** @see scope-path.hpp usage example (explicit specialisation)
@ -119,12 +124,16 @@ namespace meta {
};
/**
* Decision helper to select between returning results by value or reference.
* - when both types can not be reconciled, not type result is provided
* - when both types can not be reconciled, _no type result_ is provided;
* this case can be detected by a compile-time bool-check
* - when one of both types is `const`, the `ResType` will be const
* - when both types are LValue-references, then the result will be a reference,
* otherwise the result will be a value type
* @see IterExplorer::expand()
*/
template<typename T1, typename T2, bool = has_TypeResult<std::common_type<T1,T2>>()>
struct CommonResultYield

87
tests/library/iter-core-adapter-test.cpp
View file

@ -20,31 +20,24 @@
#include "lib/test/run.hpp"
#include "lib/test/test-helper.hpp"
#include "lib/util.hpp"
#include "lib/test/diagnostic-output.hpp"////////////TODO
#include "lib/iter-adapter.hpp"
//#include <boost/lexical_cast.hpp>
//#include <vector>
#include <string>
namespace lib {
using util::unConst;
namespace test{
using LERR_(ITER_EXHAUST);
// using boost::lexical_cast;
// using util::for_each;
// using util::isnil;
using util::isSameObject;
// using std::vector;
using std::string;
namespace {
namespace { // Test fixture
/**
* A »*State Core*« to step down numbers to zero.
* A test »*State Core*« which steps down a number to zero.
* @note this is a minimal description of a state progression towards a goal
* - default constructed is equivalent to _goal was reached_
* - can be copied, manipulated and compared
@ -83,7 +76,7 @@ namespace test{
return n == o.n;
}
};
} // (END) impl test dummy container
}// (END) test dummy
@ -95,6 +88,7 @@ namespace test{
* @test cover the concept of a »state core«, which is used in Lumiera
* for various aspects of data generation and iteration.
* @see IterStateWrapper
* @see iter-adapter.hpp
* @see iter-explorer.hpp
*/
class IterCoreAdapter_test : public Test
@ -106,14 +100,14 @@ namespace test{
stateManipulation();
checked_and_protected();
value_and_reference_yield();
verify_TypeReconciliation();
}
/** @test build a »Lumiera Forward Iterator«
* to transition a State-Core towards it final state
* to transition a State-Core towards it final state.
*/
void
simpleUsage()
@ -186,10 +180,10 @@ namespace test{
/** @test adapters can (transparently) handle a core which yields values
* - demonstrate how cores can be augmented by decoration
* - the decorated core here yields by-value
* - both CheckedCore and IterableDecorator can cope with that
* - the result is then also delivered by-value from the iterator
* - demonstrate how cores can be augmented by decoration...
* - the decorated core here yields by-value, not by-ref.
* - Both CheckedCore and IterableDecorator can cope with that
* - the result is then also delivered by-value from the iterator.
* @remark the »Lumiera Forward Iterator« concept does not exactly specify
* what to expect when dereferencing an iterator; yet for obvious reasons,
* most iterators in practice expose a reference to some underlying container
@ -199,7 +193,7 @@ namespace test{
* for the compiler, the code using the iterator is not tightly coupled). This
* scheme has ramifications for the way any iterator pipeline works; notably
* any _transformation_ will have to capture a function result. However,
* sometimes an iterator can only return a computed value; such a usage
* sometimes an iterator can only return a computed value; such an usage
* can be valid and acceptable and is supported to the degree possible.
*/
void
@ -233,6 +227,61 @@ namespace test{
}
/** @test construction of a common result type.
* - based on `std::common_type`
* - so there must be some common ground
* - if any of the types is by-value, the result is
* - if any of the types is const, the result is const
*/
void
verify_TypeReconciliation()
{
using C1 = Common<int,string>;
CHECK (not C1());
CHECK (not C1::value);
using C2 = Common<int,long*>;
CHECK (not C2()); // can not be reconciled
CHECK (not C2::value);
// using X = C2::ResType; // does not (and should not) compile
using C3 = Common<string,string>;
CHECK (C3());
CHECK (showType<C3::ResType>() == "string"_expect );
using C4 = Common<string&,string>;
CHECK (showType<C4::ResType>() == "string"_expect );
using C5 = Common<string&,string&>;
CHECK (showType<C5::ResType>() == "string&"_expect ); // ref access to both is possible
using C6 = Common<string&,string&&>;
CHECK (showType<C6::ResType>() == "string"_expect ); // caution, RValue might be a temporary
using C7 = Common<string&&,string&&>;
CHECK (showType<C7::ResType>() == "string"_expect );
using C8 = Common<string const&, string const&>;
CHECK (showType<C8::ResType>() == "string const&"_expect );
using C9 = Common<string const&, string&>;
CHECK (showType<C9::ResType>() == "string const&"_expect ); // reconcile to const&
using C10 = Common<string const&, string>;
CHECK (showType<C10::ResType>() == "const string"_expect );
using C11 = Common<string&&, string const&>;
CHECK (showType<C11::ResType>() == "const string"_expect ); // reconciled to value type
using C12 = Common<long const&, int>;
CHECK (showType<C12::ResType>() == "const long"_expect ); // reconciled to the larger number type
using C13 = Common<double&, long const&>;
CHECK (showType<C13::ResType>() == "double const&"_expect ); // usual in C++ (loss of precision possible)
}
template<typename T1, typename T2>
using Common = meta::CommonResultYield<T1,T2>;
};
LAUNCHER (IterCoreAdapter_test, "unit common");

55
tests/library/iter-zip-test.cpp
View file

@ -410,7 +410,7 @@ namespace test{
/** @test the result is actually an IterExplorer pipeline builder,
* which can be used to attach further processing.
* which can be used to attach further processing downstream.
* @note the design of IterExplorer inherently requires that
* generic lambdas accept the _iterator type_ by reference;
* structural bindings can only be used in a second step.
@ -418,6 +418,16 @@ namespace test{
void
verify_pipelining()
{
// for reference: this is the base data.......
CHECK (materialise (
zip (num31(), num32(), num33())
)
== "«tuple<uint&, uint&, uint&>»──(1,2,3)-"
"«tuple<uint&, uint&, uint&>»──(4,5,6)-"
"«tuple<uint&, uint&, uint&>»──(7,8,9)-"
"«tuple<uint&, uint&, uint&>»──(10,11,12)-"
"«tuple<uint&, uint&, uint&>»──(13,14,15)"_expect);
// transform the tuple into another data value
CHECK (materialise (
zip (num31(), num32(), num33())
@ -447,23 +457,7 @@ namespace test{
}
template<typename T1, typename T2>
void
resu()
{ MARK_TEST_FUN
using RT = meta::CommonResultYield<T1,T2>;
SHOW_EXPR(RT())
if constexpr (RT())
{
SHOW_EXPR(RT::isConst)
SHOW_EXPR(RT::isRef)
SHOW_TYPE(typename RT::_Common )
SHOW_TYPE(typename RT::_ConstT )
SHOW_TYPE(typename RT::_ValRef )
SHOW_TYPE(typename RT::ResType )
SHOW_TYPE(typename RT::reference)
}
}
/** @test verify the interplay of _child expansion_ and tuple-zipping.
* @remark the expansion mechanism implies that a _child sequence_ is generated
* by an _expand functor,_ based on the current iterator value at that point.
@ -483,18 +477,6 @@ SHOW_TYPE(typename RT::reference)
void
verify_exploration()
{
/*
resu<string,string>();
resu<string&,string>();
resu<string&,string&>();
resu<string&&,string&&>();
resu<string const&,string const&>();
resu<int, long const&>();
resu<double&, long const&>();
resu<int, string>();
resu<int, long*>();
*/
CHECK (materialise (
num31()
)
@ -519,7 +501,7 @@ SHOW_TYPE(typename RT::reference)
( eachNum(10)
, explore(num31())
.expand ([](int i){ return NumIter{noneg(i-1),i}; })
.expandAll()
.expandAll() // ◁────────────────────────────────────────────── expand triggered in source pipeline, before the zip()
, explore(num31())
.expand ([](int i){ return NumIter{noneg(i-2),i-1}; })
.expandAll()
@ -579,17 +561,6 @@ SHOW_TYPE(typename RT::reference)
"«tuple<int, uint, uint>»──(10,6,3)-"
"«tuple<int, uint, uint>»──(10,5,1)"_expect);
}
/*
SHOW_EXPR
(materialise (
zip (num31(), num32(), num33())
)
)
CHECK (materialise (
zip (num31(), num32(), num33())
)
== ""_expect);
*/
};

180
wiki/thinkPad.ichthyo.mm
View file

@ -19639,9 +19639,7 @@
<node CREATED="1665875077974" ID="ID_1931734833" MODIFIED="1665875087061" TEXT="ElementBox &#xfc;bernimmt keine Ownership"/>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1665875088220" ID="ID_734939153" LINK="#ID_1042919827" MODIFIED="1675385118681" TEXT="Lifecycle ist zu gew&#xe4;hrleisten">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
das Kind-Widget mu&#223; ElementBox &#252;berleben; und das bedeutet, es mu&#223; ein Sibling sein... (problematisch f&#252;r die Struktur vom ClipWidget, es sei denn, man macht ElementBox dort zu einem Member &#8212; was allerdings wiederum der Anforderung widerspricht, da&#223; das Clip-Delegate direkt ein Widget ist und sich darstellen kann)
@ -20117,9 +20115,7 @@
<node CREATED="1666307519219" ID="ID_757987414" MODIFIED="1666307528695" TEXT="der komische Text ist immer noch da"/>
<node CREATED="1666307529508" ID="ID_990701944" MODIFIED="1666307578878" TEXT="und auch der Size-Constraint ist sonderbar(falsch)">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
H&#246;he nur 16px, obwohl doch das Icon mindestens 18px braucht (incl.Border), und das get_required_height() diesen Wert eigentlich liefern sollte
@ -20628,9 +20624,7 @@
</body>
</html></richcontent>
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...denn:
@ -21090,9 +21084,7 @@
<node CREATED="1575216778548" ID="ID_1190748757" MODIFIED="1575216796416" TEXT="er w&#xfc;rde dann bei der Erstellung die relativen Kind-Koordinaten ausrechnen und mitgeben"/>
<node CREATED="1575216835596" ID="ID_629102178" MODIFIED="1575216885510" TEXT="die Template-Visitor-Methode wird mit einem static_fail implementiert">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
um zu dokumentieren, da&#223; wir in diesem Visitor-Mischfall am Konzept vorbei implementieren
@ -22078,9 +22070,7 @@
<node CREATED="1582504016734" ID="ID_973744286" MODIFIED="1582504028245" TEXT="entweder wir verlangen einen zu konkreten Typ"/>
<node CREATED="1582504058994" ID="ID_638337039" MODIFIED="1582504106019" TEXT="oder der Callback auf den generischen ViewHook wird vom Typsystem abgelehnt">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
weil dieses nicht wei&#223;, da&#223; es sich um eine Subtyp-Beziehung handelt
@ -23583,9 +23573,7 @@
</node>
<node CREATED="1541861495569" FOLDED="true" ID="ID_1949450244" MODIFIED="1672970963226">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
&nbsp;&#xd83e;&#xdc46; generische <b>ZoomWindow</b>-Komponente
@ -27019,9 +27007,7 @@
<icon BUILTIN="yes"/>
<node CREATED="1675901877549" ID="ID_1912760164" MODIFIED="1676042929930" TEXT="Name: StaveBracket">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
In Anspielung auf
@ -36158,9 +36144,7 @@
<node CREATED="1477343061900" ID="ID_589166101" MODIFIED="1518487921084" TEXT="Statusbar"/>
<node CREATED="1477343071827" ID="ID_369966079" MODIFIED="1576282358034" TEXT="Actions">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
Helper to build the menu and for&#160;registering and handling of user action events
@ -39701,9 +39685,7 @@
</node>
<node CREATED="1618574145104" ID="ID_1569426176" MODIFIED="1618574244273" TEXT="Gesten &#xfc;ber mehrere Eingabesysteme hinweg">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<ul>
<li>
@ -41058,9 +41040,7 @@
</node>
<node CREATED="1667683634701" ID="ID_1449451873" MODIFIED="1667685735423" TEXT="Metrik kann minimal gr&#xf6;&#xdf;er geworden sein (durch Rundung)">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
<u>Konkretes Rechenbeispiel:</u>
@ -42021,9 +42001,7 @@
</node>
<node COLOR="#435e98" CREATED="1669479223678" ID="ID_538384824" MODIFIED="1670960844426" TEXT=" Ausgang durch conformMetricToWindow">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...und das betrachte ich als gutm&#252;tig und hinreichend abgesichert...
@ -42535,9 +42513,7 @@
<icon BUILTIN="help"/>
<node CREATED="1670617550570" ID="ID_794382292" MODIFIED="1670617586580" TEXT="dieser Rechenweg stammt noch aus der initialien Implementierung">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...welche ich inzwischen nahezu komplett einmal umgepfl&#252;gt habe...
@ -42911,9 +42887,7 @@
</node>
<node CREATED="1670686892666" ID="ID_663041240" MODIFIED="1670689470564" TEXT="und : placeWindowRelativeToAnchor (dur) erfordert eine &#xb5;-Tick-quantisierte Duration">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
sonst kann man eine fehlerfreie Kalkulation nicht garantieren
@ -43336,9 +43310,7 @@
</node>
<node COLOR="#690f14" CREATED="1671153242324" ID="ID_1578460487" MODIFIED="1671216836261" TEXT="geht aber nicht besser, da Zahlen maximal giftig">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
wir rechnen von der Duration auf eine Metrik um, weil wir den Mechanismus zur relativen Positionierung haben wollen. Dieser mu&#223; aber detox() verwenden, weil sonst die Division mit der Pixel-Zahl einen numeric-wrap machen w&#252;rde....
@ -52625,13 +52597,16 @@
</html></richcontent>
</node>
</node>
<node CREATED="1732154647647" ID="ID_232099852" MODIFIED="1732154650378" TEXT="Technologie">
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1732154647647" ID="ID_232099852" MODIFIED="1732636366058" TEXT="Technologie">
<icon BUILTIN="forward"/>
<node CREATED="1732154651158" ID="ID_660736150" MODIFIED="1732154675895" TEXT="komplexes Konstrukt aus variadischen Templates"/>
<node CREATED="1732154676675" ID="ID_515540198" MODIFIED="1732154705046" TEXT="beruht auf Tuples, std::apply und dem IterExplorer als Builder"/>
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1732154713702" ID="ID_1753947869" MODIFIED="1732154721829" TEXT="per Experiment schrittweise aufbauen">
<icon BUILTIN="pencil"/>
<node CREATED="1732154727348" ID="ID_1216046809" MODIFIED="1732154731240" TEXT="IterZip_test"/>
<node COLOR="#338800" CREATED="1732207603752" ID="ID_1484345238" MODIFIED="1732220052298" TEXT="Anforderung: Funktion auf Tupel anwenden">
<node COLOR="#338800" CREATED="1732154713702" ID="ID_1753947869" MODIFIED="1732636354403" TEXT="per Experiment schrittweise aufbauen">
<icon BUILTIN="button_ok"/>
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1732154727348" ID="ID_1216046809" MODIFIED="1732636358766" TEXT="IterZip_test">
<font BOLD="true" NAME="SansSerif" SIZE="12"/>
</node>
<node COLOR="#338800" CREATED="1732207603752" FOLDED="true" ID="ID_1484345238" MODIFIED="1732636351867" TEXT="Anforderung: Funktion auf Tupel anwenden">
<icon BUILTIN="button_ok"/>
<node CREATED="1732207627754" ID="ID_1652254138" MODIFIED="1732207631076" TEXT="sollte gehen...."/>
<node CREATED="1732207631631" ID="ID_1627692250" MODIFIED="1732207639059" TEXT="ist aber &#xfc;berraschend trickreich im Detail"/>
@ -52650,16 +52625,17 @@
</node>
</node>
</node>
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1732220073140" ID="ID_1314042362" MODIFIED="1732235218812" TEXT="Iteratoren-Tupel konstruieren">
<icon BUILTIN="pencil"/>
<node COLOR="#338800" CREATED="1732220073140" FOLDED="true" ID="ID_1314042362" MODIFIED="1732636349311" TEXT="Iteratoren-Tupel konstruieren">
<icon BUILTIN="button_ok"/>
<node CREATED="1732220106650" ID="ID_230100123" MODIFIED="1732220117095" TEXT="lib::explore() sollte die eigentliche (schwere) Arbeit machen"/>
<node CREATED="1732220131993" ID="ID_1112527704" MODIFIED="1732234616020" TEXT="hoffe, da&#xdf; das mit perfect-forwarding funktioniert">
<arrowlink COLOR="#d41f46" DESTINATION="ID_1711720667" ENDARROW="Default" ENDINCLINATION="-179;-10;" ID="Arrow_ID_880963824" STARTARROW="None" STARTINCLINATION="176;10;"/>
</node>
<node COLOR="#338800" CREATED="1732220149904" ID="ID_734335248" MODIFIED="1732235197250" TEXT="im Testfall explizit durchspielen">
<icon BUILTIN="button_ok"/>
<node CREATED="1732220193074" ID="ID_322908141" MODIFIED="1732220195869" TEXT="demo_construction()"/>
<node CREATED="1732220196361" ID="ID_1154553759" MODIFIED="1732220205672" TEXT="schrittweise mit lokalen Klassen aufbauen...">
<node COLOR="#435e98" CREATED="1732220193074" ID="ID_322908141" MODIFIED="1732636334951" TEXT="demo_construction()"/>
<node COLOR="#338800" CREATED="1732220196361" FOLDED="true" ID="ID_1154553759" MODIFIED="1732636325808" TEXT="schrittweise mit lokalen Klassen aufbauen...">
<icon BUILTIN="button_ok"/>
<node COLOR="#435e98" CREATED="1732220420635" ID="ID_665925849" MODIFIED="1732234993815" TEXT="Builder f&#xfc;r das Iteratoren-Tupel">
<node CREATED="1732234471735" ID="ID_1749059928" MODIFIED="1732234491522">
<richcontent TYPE="NODE"><html>
@ -52945,8 +52921,8 @@
</node>
</node>
</node>
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1732235208972" ID="ID_1764687143" MODIFIED="1732308740170" TEXT="nun in Library-Code extrahieren">
<icon BUILTIN="pencil"/>
<node COLOR="#338800" CREATED="1732235208972" ID="ID_1764687143" MODIFIED="1732636372831" TEXT="nun in Library-Code extrahieren">
<icon BUILTIN="button_ok"/>
<node COLOR="#435e98" CREATED="1732299521810" ID="ID_185815307" MODIFIED="1732313502381" TEXT="schlank halten: es gen&#xfc;gt die ProductCore">
<icon BUILTIN="yes"/>
</node>
@ -52956,7 +52932,7 @@
<node COLOR="#338800" CREATED="1732308743486" ID="ID_1261102696" MODIFIED="1732328080578" TEXT="Pr&#xfc;fen und erweitern auf das Durchreichen von Referenzen">
<linktarget COLOR="#b36e78" DESTINATION="ID_1261102696" ENDARROW="Default" ENDINCLINATION="243;11;" ID="Arrow_ID_1182778536" SOURCE="ID_1663970369" STARTARROW="None" STARTINCLINATION="212;14;"/>
<icon BUILTIN="button_ok"/>
<node COLOR="#435e98" CREATED="1732315275749" ID="ID_769235796" MODIFIED="1732328069516" TEXT="liefert dann &#xfc;berraschend oft eine Referenz">
<node COLOR="#435e98" CREATED="1732315275749" FOLDED="true" ID="ID_769235796" MODIFIED="1732328069516" TEXT="liefert dann &#xfc;berraschend oft eine Referenz">
<icon BUILTIN="messagebox_warning"/>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1732315295690" ID="ID_565969002" MODIFIED="1732315304625" TEXT="m&#xf6;chte man das?"/>
<node CREATED="1732315305473" ID="ID_1790636201" MODIFIED="1732315324906" TEXT="ja &#x2014; und es gibt const">
@ -53143,8 +53119,8 @@
</node>
</node>
</node>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1732235272468" ID="ID_1892180908" MODIFIED="1732235318053" TEXT="gr&#xfc;ndlich testen">
<icon BUILTIN="flag-pink"/>
<node COLOR="#338800" CREATED="1732235272468" ID="ID_1892180908" MODIFIED="1732637867027" TEXT="gr&#xfc;ndlich testen">
<icon BUILTIN="button_ok"/>
<node COLOR="#338800" CREATED="1732308670586" ID="ID_351914878" MODIFIED="1732308678431" TEXT="einfaches Demo-Beispiel">
<icon BUILTIN="button_ok"/>
<node COLOR="#435e98" CREATED="1732308679924" ID="ID_762659981" MODIFIED="1732308713186" TEXT="sollte eine For-Schleife zeigen"/>
@ -53191,8 +53167,7 @@
...auch wenn es normalerweise kein Performance-Problem darstellt, weil der Optimiser redundante Aufrufe problemlos eliminiert, macht es die Typen f&#252;r den Au&#223;enstehend noch viel undurchtringbarer, und belastet auch die Debug-Builds durch den Umfang unn&#246;tiger Typ-Information
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="smily_bad"/>
</node>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1732333491869" ID="ID_34490328" MODIFIED="1732489232938" TEXT="...und w&#xfc;rde das Durchreichen eines Child-Expanders verhindern">
@ -53326,9 +53301,9 @@
<node COLOR="#338800" CREATED="1732489334100" ID="ID_744918133" MODIFIED="1732489351281" TEXT="das eigentliche Weiterleiten der Aufrufe ist trivial einfach zu implementieren">
<icon BUILTIN="button_ok"/>
</node>
<node CREATED="1732489352034" ID="ID_1389747588" MODIFIED="1732489361393" TEXT="Testen ist m&#xfc;hsam....">
<node COLOR="#435e98" CREATED="1732489352034" FOLDED="true" ID="ID_1389747588" MODIFIED="1732636282025" TEXT="Testen ist m&#xfc;hsam....">
<node BACKGROUND_COLOR="#c8c0b6" CREATED="1732499374948" ID="ID_1694141748" MODIFIED="1732576950165" TEXT="geht schon los mit....">
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1732499382404" ID="ID_298429500" MODIFIED="1732499641690" TEXT="...dem Umstand, da&#xdf; der Expander nicht auf Value-Result funktioniert">
<node COLOR="#435e98" CREATED="1732499382404" ID="ID_298429500" MODIFIED="1732636249571" TEXT="...dem Umstand, da&#xdf; der Expander nicht auf Value-Result funktioniert">
<icon BUILTIN="broken-line"/>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1732499558508" ID="ID_738246140" MODIFIED="1732499660372" TEXT="hatte das schon einmal vor ein paar Tagen erfolglos untersucht">
<linktarget COLOR="#6f141e" DESTINATION="ID_738246140" ENDARROW="Default" ENDINCLINATION="194;-414;" ID="Arrow_ID_768211036" SOURCE="ID_1689757044" STARTARROW="None" STARTINCLINATION="507;142;"/>
@ -53341,7 +53316,7 @@
</node>
<node COLOR="#435e98" CREATED="1732499748626" ID="ID_73007932" MODIFIED="1732576975282" TEXT="nochmal untersuchen: k&#xf6;nnen wir Value-Ergebnisse aus der Pipeline unterst&#xfc;tzen?">
<icon BUILTIN="help"/>
<node COLOR="#435e98" CREATED="1732499767002" ID="ID_1245640841" MODIFIED="1732576658405" TEXT="Problem-1 : der operator-&gt;">
<node COLOR="#435e98" CREATED="1732499767002" FOLDED="true" ID="ID_1245640841" MODIFIED="1732636236208" TEXT="Problem-1 : operator-&gt; kann nicht unterst&#xfc;tzt werden">
<node CREATED="1732499786605" ID="ID_1510842318" MODIFIED="1732499805038" TEXT="diesen m&#xfc;&#xdf;te man dann per conditional-Definiton entfernen"/>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1732499810538" ID="ID_1382366845" MODIFIED="1732576617138" TEXT="vielleicht ist das akzeptabel (Konsequenzen noch nicht klar...)">
<icon BUILTIN="help"/>
@ -53349,7 +53324,7 @@
<node COLOR="#435e98" CREATED="1732576632416" ID="ID_1935979671" MODIFIED="1732576647957" TEXT="noch einen static_assert eingebaut f&#xfc;r bessere Fehlermeldung"/>
</node>
</node>
<node COLOR="#435e98" CREATED="1732499843557" ID="ID_1131882712" MODIFIED="1732576661348" TEXT="Problem-2 : mu&#xdf; zwischen Value/Ref umschalten k&#xf6;nnen">
<node COLOR="#435e98" CREATED="1732499843557" FOLDED="true" ID="ID_1131882712" MODIFIED="1732636221004" TEXT="Problem-2 : mu&#xdf; zwischen Value/Ref umschalten k&#xf6;nnen">
<node CREATED="1732499861875" ID="ID_297864909" MODIFIED="1732499878292" TEXT="brauche effektiv einen weiteren &#xbb;Ausgabekanal&#xab; &#xfc;ber den Typ"/>
<node CREATED="1732499879180" ID="ID_152140001" MODIFIED="1732576772094" TEXT="denkbar: wenn die R&#xfc;ckgabetypen aufeinander aufbauen">
<richcontent TYPE="NOTE"><html>
@ -53369,8 +53344,7 @@
habe die mehrfachen Adapter nun allesamt weg; daher w&#228;re es nun doch denkbar, da die Call-Pfade nun von einem Punkt aus aufspalten (n&#228;mlich Core::yield -&gt;&#160;&#160;entweder operator* oder operator-&gt; )
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1732576781381" ID="ID_452524052" MODIFIED="1732576819125" TEXT="effektiv l&#xe4;d das das Problem bei konkreten Transformationen und Pr&#xe4;dikaten ab">
<icon BUILTIN="messagebox_warning"/>
@ -53378,7 +53352,7 @@
<node CREATED="1732576887573" ID="ID_687212437" MODIFIED="1732576907676" TEXT="erscheint akzepabel, da das i.d.R Lambdas f&#xfc;r den Einzelfall sind"/>
</node>
</node>
<node COLOR="#338800" CREATED="1732500030252" ID="ID_1233066521" MODIFIED="1732576600199" TEXT="Proof-of-Concept machen">
<node COLOR="#338800" CREATED="1732500030252" FOLDED="true" ID="ID_1233066521" MODIFIED="1732636215230" TEXT="Proof-of-Concept machen">
<icon BUILTIN="button_ok"/>
<node COLOR="#338800" CREATED="1732500037694" ID="ID_1099507221" MODIFIED="1732576467794" TEXT="neues Trait: lib::meta::CommonResultYield">
<icon BUILTIN="yes"/>
@ -53402,8 +53376,7 @@
Booo!&#160;&#160;<font face="Monospaced" color="#582e24">is_const_v&lt;T&amp;&gt;</font>&#160;ist <b><font color="#e00b0b">immer false</font></b>
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1732573450476" ID="ID_1325209644" MODIFIED="1732573474740" TEXT="und X &amp; const &#x2260; X const&amp;"/>
<node CREATED="1732576525640" ID="ID_1638928832" MODIFIED="1732576557732" TEXT="tja">
@ -53418,9 +53391,8 @@
<icon BUILTIN="smily_bad"/>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1732584495255" ID="ID_910412701" MODIFIED="1732584527089" TEXT="&#x27f6; eigens als Test dokumentieren">
<arrowlink COLOR="#d41c27" DESTINATION="ID_1750877358" ENDARROW="Default" ENDINCLINATION="1071;0;" ID="Arrow_ID_626641268" STARTARROW="None" STARTINCLINATION="364;29;"/>
<icon BUILTIN="flag-yellow"/>
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1732584495255" ID="ID_910412701" MODIFIED="1732636199249" TEXT="&#x27f6; eigens als Test dokumentiert">
<arrowlink COLOR="#1c61d4" DESTINATION="ID_1750877358" ENDARROW="Default" ENDINCLINATION="1071;0;" ID="Arrow_ID_626641268" STARTARROW="None" STARTINCLINATION="385;33;"/>
</node>
</node>
<node COLOR="#338800" CREATED="1732576300069" ID="ID_1496960816" MODIFIED="1732576458151" TEXT="IterableDecorator flexibel machen : hier Vorgabe (referenz) &#x27f7; tats&#xe4;chliches yield()">
@ -53449,8 +53421,7 @@
</li>
</ul>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1732576997102" ID="ID_1924173493" MODIFIED="1732577133634" TEXT="bestehendes System dadurch nicht gef&#xe4;hrdet">
<richcontent TYPE="NOTE"><html>
@ -53470,8 +53441,7 @@
es wird vermutlich auf wenige F&#228;lle beschr&#228;nkt bleiben, in denen es aber durchaus hilfreich ist, da sowohl Generatoren als auch Transformatoren einfacher zu schreiben sind
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
</node>
</node>
@ -53499,15 +53469,15 @@
der auto-Expander kann und darf ja nicht wissen, wo genau unterhalb die Expansion stattfindet; wenn eben gar keine stattfindet, dann bleiben alle durchgereichten expandChildren()-Aufrufe ohne Wirkung, aber ein iterNext() wird dann auch nicht mehr gesendet
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="button_ok"/>
</node>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1732584380577" ID="ID_907702003" MODIFIED="1732584406718" TEXT="nebenbei: IterableDecorator ist nun flexibler &#x27f6; Test">
<node COLOR="#338800" CREATED="1732584380577" ID="ID_907702003" MODIFIED="1732637858939" TEXT="nebenbei: IterableDecorator ist nun flexibler &#x27f6; Test">
<icon BUILTIN="yes"/>
<icon BUILTIN="button_ok"/>
<node CREATED="1732584408909" ID="ID_1774747868" MODIFIED="1732584416008" TEXT="iter-core-adapter-test.cpp">
<node CREATED="1732584417772" ID="ID_710320129" MODIFIED="1732584430262" TEXT="weil das eigentlich mit dem Thema &#xbb;State Core&#xab; zu tun hat"/>
<node CREATED="1732584430730" ID="ID_1543136731" MODIFIED="1732584440733" TEXT="...wof&#xfc;r es bisher gar keine Tests gab">
@ -53517,21 +53487,65 @@
<node COLOR="#338800" CREATED="1732584446602" ID="ID_72717134" MODIFIED="1732584461134" TEXT="sollte dann auch gleich mal die Grundmuster mit dokumentieren">
<icon BUILTIN="button_ok"/>
</node>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1732584463118" ID="ID_1750877358" MODIFIED="1732584522136" TEXT="Testfall mit den Typkonvertierungen extrahieren">
<linktarget COLOR="#d41c27" DESTINATION="ID_1750877358" ENDARROW="Default" ENDINCLINATION="1071;0;" ID="Arrow_ID_626641268" SOURCE="ID_910412701" STARTARROW="None" STARTINCLINATION="364;29;"/>
<icon BUILTIN="flag-pink"/>
<node COLOR="#338800" CREATED="1732584463118" ID="ID_1750877358" MODIFIED="1732636191954" TEXT="Testfall mit den Typkonvertierungen extrahieren">
<linktarget COLOR="#1c61d4" DESTINATION="ID_1750877358" ENDARROW="Default" ENDINCLINATION="1071;0;" ID="Arrow_ID_626641268" SOURCE="ID_910412701" STARTARROW="None" STARTINCLINATION="385;33;"/>
<icon BUILTIN="button_ok"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1732584616649" ID="ID_1631761913" MODIFIED="1732584728444" TEXT="aufr&#xe4;umen...">
<icon BUILTIN="bell"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1732584624472" ID="ID_447849996" MODIFIED="1732584637215" TEXT="Typ-Parameter von IterStateWrapper">
<icon BUILTIN="flag-yellow"/>
<node CREATED="1732584638326" ID="ID_200640906" MODIFIED="1732584651480" TEXT="der default auf dem 2.Parameter macht selten Sinn"/>
<node CREATED="1732584652068" ID="ID_1279596515" MODIFIED="1732584668049" TEXT="kann man den Typ-Parameter deduzierbar machen?"/>
<node COLOR="#338800" CREATED="1732584638326" ID="ID_200640906" MODIFIED="1732628617817" TEXT="der default auf dem 2.Parameter kann weg">
<icon BUILTIN="button_ok"/>
<node CREATED="1732628224293" ID="ID_766835440" MODIFIED="1732628228755" TEXT="er wird nie verwendet"/>
<node CREATED="1732628229301" ID="ID_744093810" MODIFIED="1732628286463" TEXT="er ist parktisch unsinnig">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
ich kann mir keinen Fall vorstellen, in dem der Default gelten k&#246;nnte; vermutlich habe ich den Default damals angeschrieben, als ich mir das Konzept neu ausgedacht habe, und mir noch nicht klar war, wohin das f&#252;hrt (und wie bedeutend das mal wird....)
</p>
</body>
</html></richcontent>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1732584709076" ID="ID_1502894530" MODIFIED="1732584720741" TEXT="Kommentare in iter-adapter">
</node>
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1732584652068" ID="ID_1279596515" MODIFIED="1732628609814" TEXT="kann man den Typ-Parameter deduzierbar machen?">
<icon BUILTIN="help"/>
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1732628298530" ID="ID_831486797" MODIFIED="1732628304606" TEXT="man k&#xf6;nnte in der Tat">
<icon BUILTIN="hourglass"/>
</node>
<node CREATED="1732628308553" ID="ID_637227327" MODIFIED="1732628328434" TEXT="dazu m&#xfc;&#xdf;te die Reihenfolge der Parameter vertauscht werden"/>
<node CREATED="1732628329022" ID="ID_1632926300" MODIFIED="1732628380419" TEXT="und der zweite Parameter m&#xfc;&#xdf;te der tats&#xe4;chliche yield-Typ sein"/>
<node CREATED="1732628383213" ID="ID_1968872393" MODIFIED="1732628509959" TEXT="es gibt einen einzigen Fall, in dem das tats&#xe4;chlich notwendig ist">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...und zwar in <b>LinkedElements</b>.
</p>
<p>
Das ist nicht <i>irgend ein Randfall, </i>sondern eine der zentralen Nutzungsm&#246;glichkeiten: um n&#228;mlich einen iterator und einen const-iterator aus der gleichen Core zu erzeugen
</p>
</body>
</html></richcontent>
</node>
<node CREATED="1732628547993" ID="ID_1897860408" MODIFIED="1732628563866" TEXT="deshalb mu&#xdf; der zweite (jetzt erste) Parameter bleiben, kann aber defaultet sein"/>
<node CREATED="1732628564623" ID="ID_1023873369" MODIFIED="1732628576939" TEXT="und w&#xfc;rde damit auch konsistent der tats&#xe4;chliche R&#xfc;ckgabetyp sein"/>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1732628578845" ID="ID_734093259" MODIFIED="1732628604773" TEXT="disruptiv &#x2014; aber substantielle Verbesserung">
<icon BUILTIN="yes"/>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1732629696172" ID="ID_830334020" MODIFIED="1732629711807" TEXT="dann auch nochmal &#xfc;ber die Parameter von IterStateWrapper nachdenken">
<icon BUILTIN="flag-yellow"/>
</node>
</node>
<node COLOR="#338800" CREATED="1732584709076" ID="ID_1502894530" MODIFIED="1732630636890" TEXT="Kommentare in iter-adapter">
<icon BUILTIN="button_ok"/>
</node>
<node COLOR="#338800" CREATED="1732584812346" ID="ID_88185433" MODIFIED="1732637846063" TEXT="Kommentare zu iter-zip">
<icon BUILTIN="button_ok"/>
</node>
</node>
</node>
</node>
</node>