Invocation: consider storage and allocation of fan-in/fan-out

At the time of the initial design attempts, I naively created a
classic interface to describe an fixed container allocated ''elsewhere.''

Meanwhile the C++ language has evolved and this whole idea looks
much more as if it could be a ''Concept'' (C++20). Moreover, having
several implementations of such a container interface is deemed inadequate,
since it would necessitate ''at least two indirections'' — while
going the Concept + Template route would allow to work without any
indirection, given our current understanding that the `ProcNode` itself
is ''not an interface'' — rather a building block.
This commit is contained in:
Fischlurch 2024-05-12 19:05:50 +02:00
parent c0d5341b15
commit db30da90ce
8 changed files with 618 additions and 2 deletions

View file

@ -33,7 +33,8 @@
** storage of variant-records, able to hold a mixture of subclasses. (the latter cases
** will be implemented when needed).
**
** @warning in rework 5/2025
** @deprecated 5/2025 to be reworked and obsoleted do not use further
** @see several-builder.hpp
** @see ref-array-test.cpp
**
*/

View file

@ -25,7 +25,8 @@
** Abstraction interface: array-like access by subscript
** @todo as of 2016, this concept seems very questionable: do we _really_ want
** to abstract over random access, or do we _actually_ want for-iteration??
** @warning in rework 5/2025
** @deprecated 5/2025 to be obsoleted by a similar design
** @see several.hpp
*/

176
src/lib/several-builder.hpp Normal file
View file

@ -0,0 +1,176 @@
/*
SEVERAL-BUILDER.hpp - builder for a limited fixed collection of elements
Copyright (C) Lumiera.org
2024, Hermann Vosseler <Ichthyostega@web.de>
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2 of
the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
/** @file several-builder.hpp
** Some (library-) implementations of the RefArray interface.
**
** Being an array-like object exposing just a const ref, it is typically used
** on interfaces, and the type of the array "elements" usually is a ABC or interface.
** The actual implementation typically holds a subclass, and is either based on a vector,
** or a fixed storage contained within the implementation. The only price to pay is
** a virtual call on element access.
**
** For advanced uses it would be possible to have a pointer-array or even an embedded
** storage of variant-records, able to hold a mixture of subclasses. (the latter cases
** will be implemented when needed).
**
** @warning WIP and in rework 5/2025 -- not clear yet where this design leads to...
** @see several-builder-test.cpp
**
*/
#ifndef LIB_SEVERAL_BUILDER_H
#define LIB_SEVERAL_BUILDER_H
#include "lib/several.hpp"
#include "include/logging.h"
#include <vector>
using std::vector;
namespace lib {
/**
* Wrap a vector holding objects of a subtype and
* provide array-like access using the interface type.
*/
template<class B, class IM = B>
class RefArrayVectorWrapper
: public RefArray<B>
{
typedef vector<IM> const& Tab;
Tab table_;
public:
RefArrayVectorWrapper (Tab toWrap)
: table_(toWrap)
{ }
virtual size_t size() const
{
return table_.size();
}
virtual B const& operator[] (size_t i) const
{
REQUIRE (i < size());
return table_[i];
}
};
/**
* This variation of the wrapper actually
* \em is a vector, but can act as a RefArray
*/
template<class B, class IM = B>
class RefArrayVector
: public vector<IM>,
public RefArrayVectorWrapper<B,IM>
{
typedef RefArrayVectorWrapper<B,IM> Wrap;
typedef vector<IM> Vect;
typedef typename Vect::size_type Size_t;
typedef typename Vect::value_type Val_t;
public:
RefArrayVector() : Vect(), Wrap((Vect&)*this) {}
RefArrayVector(Size_t n, Val_t const& v = Val_t()) : Vect(n,v), Wrap((Vect&)*this) {}
RefArrayVector(Vect const& ref) : Vect(ref), Wrap((Vect&)*this) {}
using Vect::size;
using Wrap::operator[];
};
/**
* RefArray implementation based on a fixed size array,
* i.e. the storage is embedded. Embedded subclass obj
* either need to be default constructible or be
* placed directly by a factory
*/
template<class B, size_t n, class IM = B>
class RefArrayTable
: public RefArray<B>
{
char storage_[n*sizeof(IM)];
IM* array_;
public:
RefArrayTable() ///< objects created in-place by default ctor
: array_ (reinterpret_cast<IM*> (&storage_))
{
size_t i=0;
try
{
while (i<n)
new(&array_[i++]) IM();
}
catch(...) { cleanup(i); throw; }
}
template<class FAC>
RefArrayTable(FAC& factory) ///< objects created in-place by factory
: array_ (reinterpret_cast<IM*> (&storage_))
{
size_t i=0;
try
{
while (i<n)
factory(&array_[i++]);
}
catch(...) { cleanup(i-1); throw; } // destroy finished part, without the failed object
}
~RefArrayTable() { cleanup(); }
private:
void cleanup(size_t top=n) noexcept
{
while (top) array_[--top].~IM();
}
public: //-----RefArray-Interface------------
virtual size_t size() const
{
return n;
}
virtual B const& operator[] (size_t i) const
{
REQUIRE (i < size());
return array_[i];
}
};
} // namespace lib
#endif /*LIB_SEVERAL_BUILDER_H*/

64
src/lib/several.hpp Normal file
View file

@ -0,0 +1,64 @@
/*
SEVERAL.hpp - abstraction providing a limited fixed number of elements
Copyright (C) Lumiera.org
2008, Hermann Vosseler <Ichthyostega@web.de>
2024, Hermann Vosseler <Ichthyostega@web.de>
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2 of
the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
/** @file several.hpp
** Abstraction interface: array-like access by subscript
** @todo as of 2016, this concept seems very questionable: do we _really_ want
** to abstract over random access, or do we _actually_ want for-iteration??
** @warning WIP-WIP-WIP in rework 5/2025
** @see several-builder.hpp
*/
#ifndef LIB_SEVERAL_H
#define LIB_SEVERAL_H
#include "lib/nocopy.hpp"
namespace lib {
/**
* Abstraction: Array of const references.
* Typically the return type is an interface,
* and the Implementation wraps some datastructure
* holding subclasses.
* @todo ouch -- a collection that isn't iterable... ///////////////////////TICKET #1040
* @warning in rework 5/2025
*/
template<class T>
class RefArray
: util::NonCopyable
{
public:
virtual ~RefArray() {} ///< this is an interface
virtual T const& operator[] (size_t i) const =0;
virtual size_t size() const =0;
};
} // namespace lib
#endif

View file

@ -598,6 +598,11 @@ return: 0
END
PLANNED "Several elements" SeveralBuilder_test <<END
return: 0
END
TEST "Search path walking" SearchPathSplitter_test <<END
out-lit: ➢➢a
out-lit: ➢➢a

View file

@ -22,6 +22,8 @@
/** @file ref-array-test.cpp
** unit test \ref RefArray_test
** @deprecated 5/2024 rework underway
** @see several-buider-test.cpp
*/

View file

@ -0,0 +1,246 @@
/*
SeveralBuilder(Test) - building a limited fixed collection of elements
Copyright (C) Lumiera.org
2008, Hermann Vosseler <Ichthyostega@web.de>
2024, Hermann Vosseler <Ichthyostega@web.de>
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2 of
the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
* *****************************************************/
/** @file several-builder-test.cpp
** unit test \ref SeveralBuilder_test
*/
#include "lib/test/run.hpp"
#include "lib/util.hpp"
#include "lib/several-builder.hpp"
#include <vector>
using ::test::Test;
using std::vector;
using std::rand;
namespace lib {
namespace test{
namespace { // test types
struct I
{
virtual int op(int i) const =0;
virtual ~I() {}
};
struct Sub1 : I
{
int offs_;
Sub1 (int o=1) : offs_(o) {}
int op (int i) const { return i+offs_; }
};
struct Sub2 : I
{
const char* letterz_;
Sub2() : letterz_("ABCDEFGHIJKLMNOPQRSTUVWXYZ") {}
int op (int i) const { return (int)letterz_[i % 26]; }
};
struct Sub3 : I
{
int id_;
static long sum;
static long trigger;
Sub3(int id) : id_(id)
{
sum +=id_;
if ( id_ == trigger )
throw trigger; // fail while in construction
}
~Sub3()
{
sum -=id_;
}
int op (int i) const { return i + id_; }
};
long Sub3::sum = 0;
long Sub3::trigger = -1;
} // (END) test types
/***************************************************************//**
* @test build several wrappers, each based on a different storage,
* all providing RefArray access to a given vector. The rationale
* for RefArray is to expose just the interface: the data structure
* within the actual implementation holds subclass instances of
* the specified interface.
* - RefArrayVectorWrapper is a ref to an existing vector
* - RefArrayVector subclasses std::vector
* - RefArrayTable holds a fix sized table, i.e. embedded storage
*
* @see several-builder.hpp
*/
class SeveralBuilder_test : public Test
{
virtual void
run (Arg)
{
checkWrapper();
checkVector();
checkTable();
checkTable_inplaceCreation();
checkTable_errorHandling();
}
void
checkWrapper()
{
vector<Sub2> subz(10);
RefArrayVectorWrapper<I,Sub2> subWrap (subz);
RefArray<I> & rArr (subWrap);
CHECK (subWrap.size()==subz.size());
CHECK (INSTANCEOF(I, &rArr[0]));
for (size_t i=0; i<rArr.size(); ++i)
{
CHECK (&rArr[i] == &subz[i]);
CHECK (rArr[i].op(i) == subz[i].op(i));
}
}
void
checkVector()
{
RefArrayVector<I,Sub2> subz(10);
vector<Sub2> & vect (subz);
RefArray<I> & rArr (subz);
CHECK (vect.size()==subz.size());
CHECK (INSTANCEOF(I, &rArr[0]));
for (size_t i=0; i<rArr.size(); ++i)
{
CHECK (&rArr[i] == &vect[i]);
CHECK (rArr[i].op(i) == vect[i].op(i));
}
}
#define ADR(OBJ) (ulong)&(OBJ)
void
checkTable()
{
RefArrayTable<I,20,Sub1> tab;
// creates 20 Sub1-objects in-place
// which are indeed located within the object
CHECK (sizeof(tab) >= 20 * sizeof(Sub1));
CHECK (ADR(tab) < ADR(tab[19]) && ADR(tab[19]) < ADR(tab) + sizeof(tab));
RefArray<I> & rArr (tab);
CHECK (20 == tab.size());
CHECK (INSTANCEOF(I, &rArr[0]));
for (size_t i=0; i<rArr.size(); ++i)
{
CHECK (i*sizeof(Sub1) == ADR(rArr[i]) - ADR(rArr[0]) ); // indeed array-like storage
CHECK (int(i+1) == rArr[i].op(i)); // check the known result
}
}
template<class SUB>
struct Fac ///< fabricating a series of subclass instances with varying ctor parameter
{
int offset_;
Fac ( ) : offset_ (0) {}
void operator() (void* place)
{
CHECK (place);
new(place) SUB (offset_++); // note: varying ctor parameter
}
};
void
checkTable_inplaceCreation()
{
Fac<Sub1> theFact;
RefArrayTable<I,30,Sub1> tab (theFact);
RefArray<I> & rArr (tab);
CHECK (30 == tab.size());
for (size_t i=0; i<rArr.size(); ++i)
CHECK (int(i+i) == rArr[i].op(i)); // each one has gotten another offset ctor parameter
}
void
checkTable_errorHandling()
{
for (uint i=0; i<500; ++i)
{
Sub3::sum = 0;
Sub3::trigger = (rand() % 50); // when hitting the trigger Sub3 throws
try
{
{
Fac<Sub3> factory;
RefArrayTable<I,30,Sub3> table (factory);
CHECK (Sub3::sum == (29+1)*29/2);
}
CHECK (Sub3::sum == 0);
}
catch(long id)
{
CHECK (id == Sub3::trigger);
CHECK (Sub3::sum == id);
// meaning: all objects have been cleaned up,
// with the exception of the one hitting the trigger
} }
}
};
/** Register this test class... */
LAUNCHER (SeveralBuilder_test, "unit common");
}} // namespace lib::test

View file

@ -80949,6 +80949,127 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<linktarget COLOR="#fbfed6" DESTINATION="ID_576332674" ENDARROW="Default" ENDINCLINATION="-670;-163;" ID="Arrow_ID_18042992" SOURCE="ID_1553624646" STARTARROW="None" STARTINCLINATION="525;35;"/>
<node CREATED="1715526375984" ID="ID_466368192" MODIFIED="1715526390634" TEXT="leichtgewichtiges Front-End zu einer Vector-artigen Collection"/>
<node CREATED="1715526412553" ID="ID_1310310561" MODIFIED="1715526457239" TEXT="bietet zus&#xe4;tzlich die F&#xe4;higkeit zur inplace-Allokation"/>
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1715530825487" ID="ID_744922331" MODIFIED="1715530828707" TEXT="Design">
<icon BUILTIN="pencil"/>
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1715530839818" ID="ID_1299414083" MODIFIED="1715530843266" TEXT="Analyse">
<icon BUILTIN="pencil"/>
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1715530844562" ID="ID_598901793" MODIFIED="1715530852442" TEXT="warum nicht einen Vector?">
<icon BUILTIN="help"/>
<node CREATED="1715530856096" ID="ID_1985014876" MODIFIED="1715530876386" TEXT="im Grunde brauchen wir ein Array"/>
<node CREATED="1715530878893" ID="ID_155576825" MODIFIED="1715530901590" TEXT="das Vector-Interface ist zu m&#xe4;chtig (und zu konkret)"/>
<node CREATED="1715530949227" ID="ID_1291999667" MODIFIED="1715530962507" TEXT="der Storage-Typ soll u.U verborgen bleiben">
<node CREATED="1715532362924" ID="ID_737856207" MODIFIED="1715532421822">
<richcontent TYPE="NODE"><html>
<head>
</head>
<body>
<p>
&#10233; Konsequenz: zus&#228;tzlicher Template-Parameter f&#252;r das<i>&#160;Spacing</i>
</p>
</body>
</html>
</richcontent>
</node>
<node COLOR="#5b280f" CREATED="1715532386464" ID="ID_1896451330" MODIFIED="1715532398219" TEXT="oder eben eine VTable wie in RefArray">
<icon BUILTIN="button_cancel"/>
</node>
</node>
<node CREATED="1715532455035" ID="ID_1288992537" MODIFIED="1715532458010" TEXT="ich m&#xf6;chte">
<node CREATED="1715532458922" ID="ID_716858129" MODIFIED="1715532474934" TEXT="Zugriff auf bestehende Elemente"/>
<node CREATED="1715532475464" ID="ID_618278235" MODIFIED="1715532480906" TEXT="Elemente sind aber non-const"/>
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1715532483303" ID="ID_622474774" MODIFIED="1715532787640" TEXT="konkreter Element-Typ kann erased sein?">
<icon BUILTIN="help"/>
</node>
<node CREATED="1715532503700" ID="ID_1038248531" MODIFIED="1715532511472" TEXT="L&#xe4;nge als State"/>
<node CREATED="1715532672941" ID="ID_1970537209" MODIFIED="1715532683208" TEXT="feste Gr&#xf6;&#xdf;e (unabh&#xe4;ngig von Element-Storage)"/>
<node CREATED="1715532511875" ID="ID_900046406" MODIFIED="1715532532822" TEXT="Iteration und effizienter Array-artiger Zugriff"/>
<node CREATED="1715532615345" ID="ID_1951577105" MODIFIED="1715532623856" TEXT="keinerlei Container-Mutation"/>
</node>
</node>
<node CREATED="1715532630466" ID="ID_169592902" MODIFIED="1715533548154" TEXT="mu&#xdf; dazu passenden Builder konzipieren...">
<font NAME="SansSerif" SIZE="12"/>
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1715532833936" ID="ID_1009009693" MODIFIED="1715532840949" TEXT="Problem: Link zum Allocator">
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1715532843871" ID="ID_774375232" MODIFIED="1715532859150" TEXT="entweder der Allocator wird als Pointer mitgeschleppt">
<node CREATED="1715532914728" ID="ID_1541420443" MODIFIED="1715532932838" TEXT="erfordert entweder separates Allocator-Objekt"/>
<node CREATED="1715532933475" ID="ID_504334832" MODIFIED="1715532949045" TEXT="oder Verschieben des erzeugten Containers ans Ziel"/>
<node COLOR="#5b280f" CREATED="1715532955960" ID="ID_297872931" MODIFIED="1715532962431" TEXT="keine In-Place-Erzeugung">
<icon BUILTIN="button_cancel"/>
</node>
</node>
<node CREATED="1715532860169" ID="ID_138554146" MODIFIED="1715532896564" TEXT="oder der Allocator ist statisch und generisch">
<node CREATED="1715532986380" ID="ID_1926875856" MODIFIED="1715533015979" TEXT="damit sind essentielle Architektur-Freiheitsgrade ausgeschlossen"/>
<node CREATED="1715533016635" ID="ID_453024557" MODIFIED="1715533035171">
<richcontent TYPE="NODE"><html>
<head>
</head>
<body>
<p>
oder man bekommt eine<i>&#160;implizite Runtime</i>
</p>
</body>
</html>
</richcontent>
</node>
</node>
</node>
<node CREATED="1715533077599" ID="ID_1244627320" MODIFIED="1715533080899" TEXT="sollte....">
<node CREATED="1715533082055" ID="ID_268296561" MODIFIED="1715533096294" TEXT="Elemente schrittweise implantieren k&#xf6;nnen (emplace)"/>
<node CREATED="1715533107500" ID="ID_1456027641" MODIFIED="1715533121838" TEXT="idealerweise Wachstumsf&#xe4;higkeit wie ein Vector"/>
<node CREATED="1715533124273" ID="ID_508327678" MODIFIED="1715533140797" TEXT="Inhalt eines Vectors komplett per move &#xfc;bernehmen"/>
<node CREATED="1715533141623" ID="ID_1757204023" MODIFIED="1715533168654" TEXT="Inhalt eines Array komplett &#xfc;bernehmen"/>
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1715533192160" ID="ID_1324375347" MODIFIED="1715533214590" TEXT="Problem: deleter / braucht impliziten Link zum Allocator">
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1715533228879" ID="ID_1909155403" MODIFIED="1715533251166" TEXT="der Destruktor mu&#xdf; wissen wie der Storage-Block freizugeben ist"/>
<node CREATED="1715533251792" ID="ID_1479555840" MODIFIED="1715533283445" TEXT="u.u. mu&#xdf; &#xfc;berhaupt keine Freigabe gemacht werden">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<body>
<p>
wenn die Daten &#8222;woanders&#8220; liegen
</p>
</body>
</html>
</richcontent>
</node>
<node CREATED="1715533317000" ID="ID_252143573" MODIFIED="1715533493572">
<richcontent TYPE="NODE"><html>
<head>
</head>
<body>
<p>
&#10233; das <b>Allocator-Problem</b>&#160;&#252;bertr&#228;gt sich <b>komplett</b>&#160; auf den Container selber
</p>
</body>
</html>
</richcontent>
<richcontent TYPE="NOTE"><html>
<head>
</head>
<body>
<p>
warum? weil man dann zwingend im Container selber einen &#187;Slot&#171; mit einem Functor oder Allocator-Pointer rumschleppt &#8212; oder doch wieder einen zus&#228;tzlichen Instanz-Typ-Tag
</p>
</body>
</html>
</richcontent>
</node>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1715533495624" HGAP="13" ID="ID_1919181051" MODIFIED="1715533550646" STYLE="bubble" TEXT="das ist ein schwerwiegendes Hindernis f&#xfc;r das gesamte Design" VSHIFT="5">
<edge COLOR="#fe0606"/>
<font NAME="SansSerif" SIZE="14"/>
<icon BUILTIN="clanbomber"/>
</node>
</node>
</node>
</node>
</node>
</node>