benn/lumiera_
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
lumiera_/src/lib/several-builder.hpp

618 lines
21 KiB
C++
Raw Normal View History

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.
2024-05-12 19:05:50 +02:00
/*
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
Library: better alignment handling Elements maintained within the storage should be placed such as to comply with their alignment requirements; the element spacing thus must be increased to be a multiple of the given type's alignment. This solution works in most common cases, where the alignement is not larger as the platform's bus width (typically 64bit); but for ''over-aligned types'' this scheme may still generate wrong object start positions (a completely correct solution would require to add a fixed offset to the beginning of the storage array and also to capture the alignment requirements during population and to re-check for each new type.
2024-06-11 00:57:24 +02:00
** Builder to create and populate instances of the lib::Several container.
** For mere usage, inclusion of several.hpp should be sufficient, since the
** container front-end is generic and intends to hide most details of allocation
** and element placement. It is an array-like container, but may hold subclass
** elements, while exposing only a reference to the interface type.
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.
2024-05-12 19:05:50 +02:00
**
Library: better alignment handling Elements maintained within the storage should be placed such as to comply with their alignment requirements; the element spacing thus must be increased to be a multiple of the given type's alignment. This solution works in most common cases, where the alignement is not larger as the platform's bus width (typically 64bit); but for ''over-aligned types'' this scheme may still generate wrong object start positions (a completely correct solution would require to add a fixed offset to the beginning of the storage array and also to capture the alignment requirements during population and to re-check for each new type.
2024-06-11 00:57:24 +02:00
** # Implementation data layout
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.
2024-05-12 19:05:50 +02:00
**
Library: better alignment handling Elements maintained within the storage should be placed such as to comply with their alignment requirements; the element spacing thus must be increased to be a multiple of the given type's alignment. This solution works in most common cases, where the alignement is not larger as the platform's bus width (typically 64bit); but for ''over-aligned types'' this scheme may still generate wrong object start positions (a completely correct solution would require to add a fixed offset to the beginning of the storage array and also to capture the alignment requirements during population and to re-check for each new type.
2024-06-11 00:57:24 +02:00
** The front-end container lib::Several<I> is actually just a smart-ptr referring
** to the actual data storage, which resides within an _array bucket._ Typically
** the latter is placed into memory managed by a custom allocator, most notably
** lib::AllocationCluster. However, by default, the ArrayBucket<I> will be placed
** into heap memory. All further meta information is also maintained alongside
** this data allocation, including a _deleter function_ to invoke all element
** destructors and de-allocate the bucket itself. Neither the type of the
** actual elements, nor the type of the allocator is revealed.
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.
2024-05-12 19:05:50 +02:00
**
Library: better alignment handling Elements maintained within the storage should be placed such as to comply with their alignment requirements; the element spacing thus must be increased to be a multiple of the given type's alignment. This solution works in most common cases, where the alignement is not larger as the platform's bus width (typically 64bit); but for ''over-aligned types'' this scheme may still generate wrong object start positions (a completely correct solution would require to add a fixed offset to the beginning of the storage array and also to capture the alignment requirements during population and to re-check for each new type.
2024-06-11 00:57:24 +02:00
** Since the actual data elements can (optionally) be of a different type than
** the exposed interface type \a I, additional storage and spacing is required
** in the element array. The field ArrayBucket<I>::spread defines this spacing
** and thus the offset used for subscript access.
**
** @todo this is a first implementation solution from 6/2025 — and was deemed
** _roughly adequate_ at that time, yet should be revalidated once more
** observations pertaining real-world usage are available...
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.
2024-05-12 19:05:50 +02:00
** @see several-builder-test.cpp
**
*/
#ifndef LIB_SEVERAL_BUILDER_H
#define LIB_SEVERAL_BUILDER_H
Library: attempt to build a re-alloc on top of the new adapter ...which basically ''seems doable'' now, yet turns up several unsolved problems - need a way to handle excess storage for the raw allocation - generally should relocate all metadata into the ArrayBucket - mismatch at various APIs; must re-think where to pass size explicitly - unclear yet how and where to pass the actual element type to create
2024-06-07 19:04:06 +02:00
#include "lib/error.hpp"
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.
2024-05-12 19:05:50 +02:00
#include "lib/several.hpp"
Library: attempt to build a re-alloc on top of the new adapter ...which basically ''seems doable'' now, yet turns up several unsolved problems - need a way to handle excess storage for the raw allocation - generally should relocate all metadata into the ArrayBucket - mismatch at various APIs; must re-think where to pass size explicitly - unclear yet how and where to pass the actual element type to create
2024-06-07 19:04:06 +02:00
#include "include/limits.hpp"
Library: draft skeleton of builder operations - create by forwarding allocator arguments to policy - builder-Op to append from iterator - decide to collapse the ArrayBucket class, since access is going through unsafe pointer arithmetic anyway
2024-05-28 18:52:01 +02:00
#include "lib/iter-explorer.hpp"
Library: attempt to build a re-alloc on top of the new adapter ...which basically ''seems doable'' now, yet turns up several unsolved problems - need a way to handle excess storage for the raw allocation - generally should relocate all metadata into the ArrayBucket - mismatch at various APIs; must re-think where to pass size explicitly - unclear yet how and where to pass the actual element type to create
2024-06-07 19:04:06 +02:00
#include "lib/format-string.hpp"
Library: draft skeleton of builder operations - create by forwarding allocator arguments to policy - builder-Op to append from iterator - decide to collapse the ArrayBucket class, since access is going through unsafe pointer arithmetic anyway
2024-05-28 18:52:01 +02:00
#include "lib/util.hpp"
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.
2024-05-12 19:05:50 +02:00
Library: work out Skeleton for memory-handling strategy - the basic decision is to implement ''realloc'' similar to `std::vector` - however the situation is complicated by the desire to allow arbitrary element types - ⟹ must build a strategy based on the properties of the target type - the completely dynamic growth is only possibly for trivially-movable types - can introduce a dedicated ''element type'' though, and store a trampolin handler
2024-06-04 23:24:11 +02:00
#include <type_traits>
Library: logic to select a suitable deleter - ensure the ''deleter function'' is invoked - care for proper ''deleter'' setup in case of exception while copying - need to »lock-in« on one specific kind of ''destructor invocation scheme,'' since we do not keep track of individual concrete element types
2024-06-09 17:19:40 +02:00
#include <functional>
Library: draft memory rearrangements not clear yet how to handle the classical "realloc" situation
2024-05-29 01:01:16 +02:00
#include <cstring>
Library: implement access to storage and subscript ...not sure if this approach works out OK, since we can not make a safe downcast to a size known at runtime
2024-05-28 18:07:08 +02:00
#include <utility>
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.
2024-05-12 19:05:50 +02:00
#include <vector>
Library: implement access to storage and subscript ...not sure if this approach works out OK, since we can not make a safe downcast to a size known at runtime
2024-05-28 18:07:08 +02:00
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.
2024-05-12 19:05:50 +02:00
namespace lib {
Library: attempt to build a re-alloc on top of the new adapter ...which basically ''seems doable'' now, yet turns up several unsolved problems - need a way to handle excess storage for the raw allocation - generally should relocate all metadata into the ArrayBucket - mismatch at various APIs; must re-think where to pass size explicitly - unclear yet how and where to pass the actual element type to create
2024-06-07 19:04:06 +02:00
namespace err = lumiera::error;
Library: draft skeleton of builder operations - create by forwarding allocator arguments to policy - builder-Op to append from iterator - decide to collapse the ArrayBucket class, since access is going through unsafe pointer arithmetic anyway
2024-05-28 18:52:01 +02:00
using std::vector;
using std::forward;
using std::move;
Library: draft memory rearrangements not clear yet how to handle the classical "realloc" situation
2024-05-29 01:01:16 +02:00
using std::byte;
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.
2024-05-12 19:05:50 +02:00
Library: draft memory rearrangements not clear yet how to handle the classical "realloc" situation
2024-05-29 01:01:16 +02:00
namespace {// Allocation management policies
Library: data layout for the new `Several` container - favour dynamic polymorphism - use additional memory for management data alongside the element allocation - encode a flag and a deleter pointer to enable ownership of the allocation - inherit base container privately into builder, so the build ends with a slice
2024-05-28 17:20:34 +02:00
Library: integrate storage-management logic Parts of this logic were first coded down in the `realloc` template method, where it did not really belong; thus reintegrate similar logic one level above, in the SeveralBuilder::adjustStorage(). Moreover, for performance reasons, always start with an initial chunk, similar to what `std::vector` does...
2024-06-08 23:59:47 +02:00
/** number of storage slots to open initially;
* starting with an over-allocation similar to `std::vector`
*/
const uint INITIAL_ELM_CNT = 10;
Library: attempt to build a re-alloc on top of the new adapter ...which basically ''seems doable'' now, yet turns up several unsolved problems - need a way to handle excess storage for the raw allocation - generally should relocate all metadata into the ArrayBucket - mismatch at various APIs; must re-think where to pass size explicitly - unclear yet how and where to pass the actual element type to create
2024-06-07 19:04:06 +02:00
using util::max;
using util::min;
using util::_Fmt;
Library: reassess logic to reject some types for existing container `lib::Several` is designed to be highly adaptable, allowing for several quite distinct usage styles. On the downside, this requires to perform some checks at runtime only, since the ability to handle some element depends on specific circumstances. This is a notable difference to `std::vector`, which is simply not capable of handling ''non-copyable'' types, even if given an up-front memory reservation. The last test case provided with the previous changeset did not trigger an exception, but closer investigation revealed that this is correct, since in this specific situation the container can accept this object type, thereby just loosing the ability to move-relocate further objects. A slightly re-arranged test scenario can be used to demonstrate this fine point.
2024-06-12 17:07:55 +02:00
using std::is_nothrow_move_constructible_v;
Library: rearrange strategy code Parts of the decision logic for element handling was packaged as separate »strategy« class — but this turned out to be neither a real abstraction, nor configurable in any way. Thus it is better to simplify the structure and turn these type predicates into simple private member functions of the SeveralBuilder itself
2024-06-11 02:48:23 +02:00
using std::is_trivially_move_constructible_v;
Library: work out a solution how to store a Deleter functor After some fruitless attempts, I settled for using std::function directly, in order to establish a working baseline of this (tremendously complicated) allocation logic. Storing a std::function in the ArrayBucket is certainly wasteful (it costs 4 »slots« of memory), but has the upside that it handles all those tricky corner cases magically; notably the functor can be stored completely inline in the most relevant case where the allocator is a monostate; moreover we bind a lambda, which can be optimised very effectively, so that in the simplest case there will be only the single indirection through the ''invoker''. This **completes the code path for a simple usage cycle** 🠲 ''and hooray ... the test crashes with a double-free''
2024-06-09 23:45:24 +02:00
using std::is_trivially_destructible_v;
Library: rearrange strategy code Parts of the decision logic for element handling was packaged as separate »strategy« class — but this turned out to be neither a real abstraction, nor configurable in any way. Thus it is better to simplify the structure and turn these type predicates into simple private member functions of the SeveralBuilder itself
2024-06-11 02:48:23 +02:00
using std::has_virtual_destructor_v;
using std::is_trivially_copyable_v;
Library: reassess logic to reject some types for existing container `lib::Several` is designed to be highly adaptable, allowing for several quite distinct usage styles. On the downside, this requires to perform some checks at runtime only, since the ability to handle some element depends on specific circumstances. This is a notable difference to `std::vector`, which is simply not capable of handling ''non-copyable'' types, even if given an up-front memory reservation. The last test case provided with the previous changeset did not trigger an exception, but closer investigation revealed that this is correct, since in this specific situation the container can accept this object type, thereby just loosing the ability to move-relocate further objects. A slightly re-arranged test scenario can be used to demonstrate this fine point.
2024-06-12 17:07:55 +02:00
using std::is_copy_constructible_v;
Library: builder to add heterogeneous elements ...turns out that we must ensure to pass a plain "object" type to the standard allocator framework (no const, no references). Here, ''object in C++ terminology'' means a scalar or record type, but no functor, no references and no void,
2024-06-11 23:22:00 +02:00
using std::is_object_v;
using std::is_volatile_v;
using std::is_const_v;
Library: rearrange strategy code Parts of the decision logic for element handling was packaged as separate »strategy« class — but this turned out to be neither a real abstraction, nor configurable in any way. Thus it is better to simplify the structure and turn these type predicates into simple private member functions of the SeveralBuilder itself
2024-06-11 02:48:23 +02:00
using std::is_same_v;
using lib::meta::is_Subclass;
Library: work out adaptor solution for custom allocator ...turns out to be rather challenging, due to the far reaching requirements * the default case (heap allocation) ''must work out-of-the box'' * optionally a C++ standard conformant `Allocator` can be adapted * which works correct even in case this allocator is ''not a monostate'' * **essential requirement** is to pass an `AllocationCluster` reference directly * need a ''generic extension point'' to adapt to similar elaborate custom schemes __Note__: especially we want to create a direct collaboration between the allocation policy and the underlying allocator to allow support for a dedicate ''realloc operation''
2024-06-06 23:15:49 +02:00
Library: better alignment handling Elements maintained within the storage should be placed such as to comply with their alignment requirements; the element spacing thus must be increased to be a multiple of the given type's alignment. This solution works in most common cases, where the alignement is not larger as the platform's bus width (typically 64bit); but for ''over-aligned types'' this scheme may still generate wrong object start positions (a completely correct solution would require to add a fixed offset to the beginning of the storage array and also to capture the alignment requirements during population and to re-check for each new type.
2024-06-11 00:57:24 +02:00
/**
* Helper to determine the »spread« required to hold
* elements of type \a TY in memory _with proper alignment._
* @warning assumes that the start of the buffer is also suitably aligned,
* which _may not be the case_ for **over-aligned objects** with
* `alignof(TY) > alignof(void*)`
*/
template<typename TY>
size_t inline constexpr
reqSiz()
{
size_t quant = alignof(TY);
size_t siz = max (sizeof(TY), quant);
size_t req = (siz/quant) * quant;
if (req < siz)
req += quant;
return req;
}
Library: consider to align this with the »Factory« concept even while at first sight only a ''deleter instance'' is required, it seems prudent to rearrange the code in accordance to the prospective Allocator / Object Factory concept, and rather try to incorporate the specifics of the memory layout into this generic view, thereby abstracting the actual allocator away. This can be achieved by using a standard-allocator for `std::byte` as the base allocator and treat each individual element allocator as a specialised cross-allocator (assuming that this cross adaptation is actually trivial in almost all cases)
2024-06-06 21:13:50 +02:00
template<class I, template<typename> class ALO>
Library: rearrange into standard allocation factory - code spelled out as intended, according to generic scheme - can now encode the »unmanaged« case directly as `null`-deleter, because in all other cases a deleter function is mandatory now - add default constructor to `ArrayBucket`, detailing the default spread
2024-06-06 21:53:04 +02:00
class ElementFactory
Library: consider to align this with the »Factory« concept even while at first sight only a ''deleter instance'' is required, it seems prudent to rearrange the code in accordance to the prospective Allocator / Object Factory concept, and rather try to incorporate the specifics of the memory layout into this generic view, thereby abstracting the actual allocator away. This can be achieved by using a standard-allocator for `std::byte` as the base allocator and treat each individual element allocator as a specialised cross-allocator (assuming that this cross adaptation is actually trivial in almost all cases)
2024-06-06 21:13:50 +02:00
: private ALO<std::byte>
Library: sketch for a deleter trampoline for simple allocators this can be static
2024-06-06 18:41:07 +02:00
{
Library: consider to align this with the »Factory« concept even while at first sight only a ''deleter instance'' is required, it seems prudent to rearrange the code in accordance to the prospective Allocator / Object Factory concept, and rather try to incorporate the specifics of the memory layout into this generic view, thereby abstracting the actual allocator away. This can be achieved by using a standard-allocator for `std::byte` as the base allocator and treat each individual element allocator as a specialised cross-allocator (assuming that this cross adaptation is actually trivial in almost all cases)
2024-06-06 21:13:50 +02:00
using Allo = ALO<std::byte>;
Library: sketch for a deleter trampoline for simple allocators this can be static
2024-06-06 18:41:07 +02:00
using AlloT = std::allocator_traits<Allo>;
Library: rearrange into standard allocation factory - code spelled out as intended, according to generic scheme - can now encode the »unmanaged« case directly as `null`-deleter, because in all other cases a deleter function is mandatory now - add default constructor to `ArrayBucket`, detailing the default spread
2024-06-06 21:53:04 +02:00
using Bucket = ArrayBucket<I>;
Library: sketch for a deleter trampoline for simple allocators this can be static
2024-06-06 18:41:07 +02:00
Library: consider to align this with the »Factory« concept even while at first sight only a ''deleter instance'' is required, it seems prudent to rearrange the code in accordance to the prospective Allocator / Object Factory concept, and rather try to incorporate the specifics of the memory layout into this generic view, thereby abstracting the actual allocator away. This can be achieved by using a standard-allocator for `std::byte` as the base allocator and treat each individual element allocator as a specialised cross-allocator (assuming that this cross adaptation is actually trivial in almost all cases)
2024-06-06 21:13:50 +02:00
Allo& baseAllocator() { return *this; }
Library: sketch for a deleter trampoline for simple allocators this can be static
2024-06-06 18:41:07 +02:00
template<typename X>
Library: consider to align this with the »Factory« concept even while at first sight only a ''deleter instance'' is required, it seems prudent to rearrange the code in accordance to the prospective Allocator / Object Factory concept, and rather try to incorporate the specifics of the memory layout into this generic view, thereby abstracting the actual allocator away. This can be achieved by using a standard-allocator for `std::byte` as the base allocator and treat each individual element allocator as a specialised cross-allocator (assuming that this cross adaptation is actually trivial in almost all cases)
2024-06-06 21:13:50 +02:00
auto
Library: sketch for a deleter trampoline for simple allocators this can be static
2024-06-06 18:41:07 +02:00
adaptAllocator()
{
using XAllo = typename AlloT::template rebind_alloc<X>;
if constexpr (std::is_constructible_v<XAllo, Allo>)
Library: consider to align this with the »Factory« concept even while at first sight only a ''deleter instance'' is required, it seems prudent to rearrange the code in accordance to the prospective Allocator / Object Factory concept, and rather try to incorporate the specifics of the memory layout into this generic view, thereby abstracting the actual allocator away. This can be achieved by using a standard-allocator for `std::byte` as the base allocator and treat each individual element allocator as a specialised cross-allocator (assuming that this cross adaptation is actually trivial in almost all cases)
2024-06-06 21:13:50 +02:00
return XAllo{baseAllocator()};
Library: sketch for a deleter trampoline for simple allocators this can be static
2024-06-06 18:41:07 +02:00
else
return XAllo{};
}
Library: rearrange into standard allocation factory - code spelled out as intended, according to generic scheme - can now encode the »unmanaged« case directly as `null`-deleter, because in all other cases a deleter function is mandatory now - add default constructor to `ArrayBucket`, detailing the default spread
2024-06-06 21:53:04 +02:00
public:
Library: consider to align this with the »Factory« concept even while at first sight only a ''deleter instance'' is required, it seems prudent to rearrange the code in accordance to the prospective Allocator / Object Factory concept, and rather try to incorporate the specifics of the memory layout into this generic view, thereby abstracting the actual allocator away. This can be achieved by using a standard-allocator for `std::byte` as the base allocator and treat each individual element allocator as a specialised cross-allocator (assuming that this cross adaptation is actually trivial in almost all cases)
2024-06-06 21:13:50 +02:00
ElementFactory (Allo allo = Allo{})
: Allo{std::move (allo)}
{ }
Library: rearrange into standard allocation factory - code spelled out as intended, according to generic scheme - can now encode the »unmanaged« case directly as `null`-deleter, because in all other cases a deleter function is mandatory now - add default constructor to `ArrayBucket`, detailing the default spread
2024-06-06 21:53:04 +02:00
Bucket*
create (size_t cnt, size_t spread)
{
Library: adapt allocation and realloc to new layout significantly simplifies both API and calculations, since all necessary data is now within the ArrayBucket
2024-06-07 22:50:24 +02:00
size_t storageBytes = Bucket::requiredStorage (cnt, spread);
Library: rearrange into standard allocation factory - code spelled out as intended, according to generic scheme - can now encode the »unmanaged« case directly as `null`-deleter, because in all other cases a deleter function is mandatory now - add default constructor to `ArrayBucket`, detailing the default spread
2024-06-06 21:53:04 +02:00
std::byte* loc = AlloT::allocate (baseAllocator(), storageBytes);
Library: adapt allocation and realloc to new layout significantly simplifies both API and calculations, since all necessary data is now within the ArrayBucket
2024-06-07 22:50:24 +02:00
Bucket* bucket = reinterpret_cast<Bucket*> (loc);
Library: rearrange into standard allocation factory - code spelled out as intended, according to generic scheme - can now encode the »unmanaged« case directly as `null`-deleter, because in all other cases a deleter function is mandatory now - add default constructor to `ArrayBucket`, detailing the default spread
2024-06-06 21:53:04 +02:00
using BucketAlloT = typename AlloT::template rebind_traits<Bucket>;
auto bucketAllo = adaptAllocator<Bucket>();
Library: basic functionality of the Several-container working ...passes the simplest unit test * create a Several<int> * populate from `std::initializer_list` * random-access to elements ''next step would be to implement iteration''
2024-06-10 18:52:25 +02:00
try { BucketAlloT::construct (bucketAllo, bucket, cnt*spread, spread); }
Library: rearrange into standard allocation factory - code spelled out as intended, according to generic scheme - can now encode the »unmanaged« case directly as `null`-deleter, because in all other cases a deleter function is mandatory now - add default constructor to `ArrayBucket`, detailing the default spread
2024-06-06 21:53:04 +02:00
catch(...)
{
AlloT::deallocate (baseAllocator(), loc, storageBytes);
throw;
}
Library: adapt allocation and realloc to new layout significantly simplifies both API and calculations, since all necessary data is now within the ArrayBucket
2024-06-07 22:50:24 +02:00
return bucket;
Library: rearrange into standard allocation factory - code spelled out as intended, according to generic scheme - can now encode the »unmanaged« case directly as `null`-deleter, because in all other cases a deleter function is mandatory now - add default constructor to `ArrayBucket`, detailing the default spread
2024-06-06 21:53:04 +02:00
};
template<class E, typename...ARGS>
E&
createAt (Bucket* bucket, size_t idx, ARGS&& ...args)
{
REQUIRE (bucket);
using ElmAlloT = typename AlloT::template rebind_traits<E>;
auto elmAllo = adaptAllocator<E>();
Library: elaborate `SeveralBuilder` operations Consider what (not) to support. Notably I decided ''not to support'' moving out of an iterator, since doing so would contradict the fundamental assumptions of the »Lumiera Forward Iterator« Concept. Start verifying some variations of element placement, still focussing on the simple cases
2024-06-11 18:23:48 +02:00
E* loc = reinterpret_cast<E*> (& bucket->subscript (idx));
Library: rearrange into standard allocation factory - code spelled out as intended, according to generic scheme - can now encode the »unmanaged« case directly as `null`-deleter, because in all other cases a deleter function is mandatory now - add default constructor to `ArrayBucket`, detailing the default spread
2024-06-06 21:53:04 +02:00
ElmAlloT::construct (elmAllo, loc, forward<ARGS> (args)...);
ENSURE (loc);
return *loc;
};
Library: consider to align this with the »Factory« concept even while at first sight only a ''deleter instance'' is required, it seems prudent to rearrange the code in accordance to the prospective Allocator / Object Factory concept, and rather try to incorporate the specifics of the memory layout into this generic view, thereby abstracting the actual allocator away. This can be achieved by using a standard-allocator for `std::byte` as the base allocator and treat each individual element allocator as a specialised cross-allocator (assuming that this cross adaptation is actually trivial in almost all cases)
2024-06-06 21:13:50 +02:00
template<class E>
void
Library: adapt allocation and realloc to new layout significantly simplifies both API and calculations, since all necessary data is now within the ArrayBucket
2024-06-07 22:50:24 +02:00
destroy (ArrayBucket<I>* bucket)
Library: sketch for a deleter trampoline for simple allocators this can be static
2024-06-06 18:41:07 +02:00
{
Library: consider to align this with the »Factory« concept even while at first sight only a ''deleter instance'' is required, it seems prudent to rearrange the code in accordance to the prospective Allocator / Object Factory concept, and rather try to incorporate the specifics of the memory layout into this generic view, thereby abstracting the actual allocator away. This can be achieved by using a standard-allocator for `std::byte` as the base allocator and treat each individual element allocator as a specialised cross-allocator (assuming that this cross adaptation is actually trivial in almost all cases)
2024-06-06 21:13:50 +02:00
REQUIRE (bucket);
Library: work out a solution how to store a Deleter functor After some fruitless attempts, I settled for using std::function directly, in order to establish a working baseline of this (tremendously complicated) allocation logic. Storing a std::function in the ArrayBucket is certainly wasteful (it costs 4 »slots« of memory), but has the upside that it handles all those tricky corner cases magically; notably the functor can be stored completely inline in the most relevant case where the allocator is a monostate; moreover we bind a lambda, which can be optimised very effectively, so that in the simplest case there will be only the single indirection through the ''invoker''. This **completes the code path for a simple usage cycle** 🠲 ''and hooray ... the test crashes with a double-free''
2024-06-09 23:45:24 +02:00
if (not is_trivially_destructible_v<E>)
{
size_t cnt = bucket->cnt;
using ElmAlloT = typename AlloT::template rebind_traits<E>;
auto elmAllo = adaptAllocator<E>();
for (size_t idx=0; idx<cnt; ++idx)
Library: elaborate `SeveralBuilder` operations Consider what (not) to support. Notably I decided ''not to support'' moving out of an iterator, since doing so would contradict the fundamental assumptions of the »Lumiera Forward Iterator« Concept. Start verifying some variations of element placement, still focussing on the simple cases
2024-06-11 18:23:48 +02:00
{
E* elm = reinterpret_cast<E*> (& bucket->subscript (idx));
ElmAlloT::destroy (elmAllo, elm);
}
Library: work out a solution how to store a Deleter functor After some fruitless attempts, I settled for using std::function directly, in order to establish a working baseline of this (tremendously complicated) allocation logic. Storing a std::function in the ArrayBucket is certainly wasteful (it costs 4 »slots« of memory), but has the upside that it handles all those tricky corner cases magically; notably the functor can be stored completely inline in the most relevant case where the allocator is a monostate; moreover we bind a lambda, which can be optimised very effectively, so that in the simplest case there will be only the single indirection through the ''invoker''. This **completes the code path for a simple usage cycle** 🠲 ''and hooray ... the test crashes with a double-free''
2024-06-09 23:45:24 +02:00
}
Library: basic functionality of the Several-container working ...passes the simplest unit test * create a Several<int> * populate from `std::initializer_list` * random-access to elements ''next step would be to implement iteration''
2024-06-10 18:52:25 +02:00
size_t storageBytes = Bucket::requiredStorage (bucket->buffSiz);
Library: adapt allocation and realloc to new layout significantly simplifies both API and calculations, since all necessary data is now within the ArrayBucket
2024-06-07 22:50:24 +02:00
std::byte* loc = reinterpret_cast<std::byte*> (bucket);
AlloT::deallocate (baseAllocator(), loc, storageBytes);
Library: sketch for a deleter trampoline for simple allocators this can be static
2024-06-06 18:41:07 +02:00
};
};
Library: rearrange logic for trivial move detection ...still fighting to get the design of the `AllocationPolicy` settled to work well with `AllocationCluster` while also allowing to handle data types which are (not) trivially copyable. This changeset attempts to turn the logic round: now we capture an ''move exclusion flag'' and otherwise allow the Policy to decide on its own, based on the ''element type''
2024-06-08 21:58:04 +02:00
template<class I, class E, template<typename> class ALO>
Library: work out adaptor solution for custom allocator ...turns out to be rather challenging, due to the far reaching requirements * the default case (heap allocation) ''must work out-of-the box'' * optionally a C++ standard conformant `Allocator` can be adapted * which works correct even in case this allocator is ''not a monostate'' * **essential requirement** is to pass an `AllocationCluster` reference directly * need a ''generic extension point'' to adapt to similar elaborate custom schemes __Note__: especially we want to create a direct collaboration between the allocation policy and the underlying allocator to allow support for a dedicate ''realloc operation''
2024-06-06 23:15:49 +02:00
struct AllocationPolicy
: ElementFactory<I, ALO>
{
using Fac = ElementFactory<I, ALO>;
Library: attempt to build a re-alloc on top of the new adapter ...which basically ''seems doable'' now, yet turns up several unsolved problems - need a way to handle excess storage for the raw allocation - generally should relocate all metadata into the ArrayBucket - mismatch at various APIs; must re-think where to pass size explicitly - unclear yet how and where to pass the actual element type to create
2024-06-07 19:04:06 +02:00
using Bucket = ArrayBucket<I>;
using Fac::Fac; // pass-through ctor
Library: work out adaptor solution for custom allocator ...turns out to be rather challenging, due to the far reaching requirements * the default case (heap allocation) ''must work out-of-the box'' * optionally a C++ standard conformant `Allocator` can be adapted * which works correct even in case this allocator is ''not a monostate'' * **essential requirement** is to pass an `AllocationCluster` reference directly * need a ''generic extension point'' to adapt to similar elaborate custom schemes __Note__: especially we want to create a direct collaboration between the allocation policy and the underlying allocator to allow support for a dedicate ''realloc operation''
2024-06-06 23:15:49 +02:00
Library: integrate strategy for acceptable element types Draft skeleton of the logic for element creation. This turns out to be a rather challenging piece of code, since we have to rely on logical reasoning about properties of the element types in order to decide if and how these elements can be emplaced, including the possibility to re-allocate and move existing data to a new location. - if we know the exact element type, we can handle any copyable or movable object - however, if the container is filled with a mixture of types, we can not re-allocate or grow dynamically, unless all data is trivially copyable (and can thus be handled through memmove) - moreover we must ensure the ability to invoke the proper destructor
2024-06-08 01:51:32 +02:00
const bool isDisposable{false}; ///< memory must be explicitly deallocated
Library: logic to accept further elements - verifies if new element can just fit in - otherwise ensure the storage adjustments are basically possible - throw exception in case the new element can not be accommodated - else request possible storage adjustments - and finally let the allocator place the new element
2024-06-08 17:35:14 +02:00
bool canExpand(size_t){ return false; }
Library: integrate strategy for acceptable element types Draft skeleton of the logic for element creation. This turns out to be a rather challenging piece of code, since we have to rely on logical reasoning about properties of the element types in order to decide if and how these elements can be emplaced, including the possibility to re-allocate and move existing data to a new location. - if we know the exact element type, we can handle any copyable or movable object - however, if the container is filled with a mixture of types, we can not re-allocate or grow dynamically, unless all data is trivially copyable (and can thus be handled through memmove) - moreover we must ensure the ability to invoke the proper destructor
2024-06-08 01:51:32 +02:00
Library: attempt to build a re-alloc on top of the new adapter ...which basically ''seems doable'' now, yet turns up several unsolved problems - need a way to handle excess storage for the raw allocation - generally should relocate all metadata into the ArrayBucket - mismatch at various APIs; must re-think where to pass size explicitly - unclear yet how and where to pass the actual element type to create
2024-06-07 19:04:06 +02:00
Bucket*
Library: simplified and generic `realloc` since this is meant as a policy implementation, reduce it to the bare operation; the actual container storage handling logic shall be implemented in the container and based on those primitive and configurable base operations
2024-06-08 22:44:07 +02:00
realloc (Bucket* data, size_t cnt, size_t spread)
Library: work out adaptor solution for custom allocator ...turns out to be rather challenging, due to the far reaching requirements * the default case (heap allocation) ''must work out-of-the box'' * optionally a C++ standard conformant `Allocator` can be adapted * which works correct even in case this allocator is ''not a monostate'' * **essential requirement** is to pass an `AllocationCluster` reference directly * need a ''generic extension point'' to adapt to similar elaborate custom schemes __Note__: especially we want to create a direct collaboration between the allocation policy and the underlying allocator to allow support for a dedicate ''realloc operation''
2024-06-06 23:15:49 +02:00
{
Library: simplified and generic `realloc` since this is meant as a policy implementation, reduce it to the bare operation; the actual container storage handling logic shall be implemented in the container and based on those primitive and configurable base operations
2024-06-08 22:44:07 +02:00
Bucket* newBucket = Fac::create (cnt, spread);
if (data)
Library: logic to select a suitable deleter - ensure the ''deleter function'' is invoked - care for proper ''deleter'' setup in case of exception while copying - need to »lock-in« on one specific kind of ''destructor invocation scheme,'' since we do not keep track of individual concrete element types
2024-06-09 17:19:40 +02:00
try {
newBucket->deleter = data->deleter;
size_t elms = min (cnt, data->cnt);
for (size_t idx=0; idx<elms; ++idx)
moveElem(idx, data, newBucket);
data->destroy();
}
catch(...)
{ newBucket->destroy(); }
Library: simplified and generic `realloc` since this is meant as a policy implementation, reduce it to the bare operation; the actual container storage handling logic shall be implemented in the container and based on those primitive and configurable base operations
2024-06-08 22:44:07 +02:00
return newBucket;
Library: work out adaptor solution for custom allocator ...turns out to be rather challenging, due to the far reaching requirements * the default case (heap allocation) ''must work out-of-the box'' * optionally a C++ standard conformant `Allocator` can be adapted * which works correct even in case this allocator is ''not a monostate'' * **essential requirement** is to pass an `AllocationCluster` reference directly * need a ''generic extension point'' to adapt to similar elaborate custom schemes __Note__: especially we want to create a direct collaboration between the allocation policy and the underlying allocator to allow support for a dedicate ''realloc operation''
2024-06-06 23:15:49 +02:00
}
Library: simplified and generic `realloc` since this is meant as a policy implementation, reduce it to the bare operation; the actual container storage handling logic shall be implemented in the container and based on those primitive and configurable base operations
2024-06-08 22:44:07 +02:00
void
moveElem (size_t idx, Bucket* src, Bucket* tar)
{
if constexpr (is_trivially_copyable_v<E>)
{
void* oldPos = & src->subscript(idx);
void* newPos = & tar->subscript(idx);
size_t amount = min (src->spread, tar->spread);
std::memmove (newPos, oldPos, amount);
}
else
Library: reassess logic to reject some types for existing container `lib::Several` is designed to be highly adaptable, allowing for several quite distinct usage styles. On the downside, this requires to perform some checks at runtime only, since the ability to handle some element depends on specific circumstances. This is a notable difference to `std::vector`, which is simply not capable of handling ''non-copyable'' types, even if given an up-front memory reservation. The last test case provided with the previous changeset did not trigger an exception, but closer investigation revealed that this is correct, since in this specific situation the container can accept this object type, thereby just loosing the ability to move-relocate further objects. A slightly re-arranged test scenario can be used to demonstrate this fine point.
2024-06-12 17:07:55 +02:00
if constexpr (is_nothrow_move_constructible_v<E>
or is_copy_constructible_v<E>)
Library: simplified and generic `realloc` since this is meant as a policy implementation, reduce it to the bare operation; the actual container storage handling logic shall be implemented in the container and based on those primitive and configurable base operations
2024-06-08 22:44:07 +02:00
{
Library: investigate case with known element type - the test-dummy objects need a `noexcept` move ctor - **bug** here: need an explicit check to prevent other types than the known element type from ''sneaking in''
2024-06-12 03:23:20 +02:00
E& oldElm = reinterpret_cast<E&> (src->subscript (idx));
Library: simplified and generic `realloc` since this is meant as a policy implementation, reduce it to the bare operation; the actual container storage handling logic shall be implemented in the container and based on those primitive and configurable base operations
2024-06-08 22:44:07 +02:00
Fac::template createAt<E> (tar, idx
Library: investigate case with known element type - the test-dummy objects need a `noexcept` move ctor - **bug** here: need an explicit check to prevent other types than the known element type from ''sneaking in''
2024-06-12 03:23:20 +02:00
,std::move_if_noexcept (oldElm));
Library: simplified and generic `realloc` since this is meant as a policy implementation, reduce it to the bare operation; the actual container storage handling logic shall be implemented in the container and based on those primitive and configurable base operations
2024-06-08 22:44:07 +02:00
}
Library: reassess logic to reject some types for existing container `lib::Several` is designed to be highly adaptable, allowing for several quite distinct usage styles. On the downside, this requires to perform some checks at runtime only, since the ability to handle some element depends on specific circumstances. This is a notable difference to `std::vector`, which is simply not capable of handling ''non-copyable'' types, even if given an up-front memory reservation. The last test case provided with the previous changeset did not trigger an exception, but closer investigation revealed that this is correct, since in this specific situation the container can accept this object type, thereby just loosing the ability to move-relocate further objects. A slightly re-arranged test scenario can be used to demonstrate this fine point.
2024-06-12 17:07:55 +02:00
else
{
NOTREACHED("realloc immovable type (neither trivially nor typed movable)");
// this alternative code section is very important, because it allows
// to instantiate this code even for »noncopyable« types, assuming that
// sufficient storage is reserved beforehand, and thus copying is irrelevant.
// For context: the std::vector impl. from libStdC++ is lacking this option.
}
Library: work out a solution how to store a Deleter functor After some fruitless attempts, I settled for using std::function directly, in order to establish a working baseline of this (tremendously complicated) allocation logic. Storing a std::function in the ArrayBucket is certainly wasteful (it costs 4 »slots« of memory), but has the upside that it handles all those tricky corner cases magically; notably the functor can be stored completely inline in the most relevant case where the allocator is a monostate; moreover we bind a lambda, which can be optimised very effectively, so that in the simplest case there will be only the single indirection through the ''invoker''. This **completes the code path for a simple usage cycle** 🠲 ''and hooray ... the test crashes with a double-free''
2024-06-09 23:45:24 +02:00
tar->cnt = idx+1; // mark fill continuously for proper clean-up after exception
Library: simplified and generic `realloc` since this is meant as a policy implementation, reduce it to the bare operation; the actual container storage handling logic shall be implemented in the container and based on those primitive and configurable base operations
2024-06-08 22:44:07 +02:00
}
Library: work out adaptor solution for custom allocator ...turns out to be rather challenging, due to the far reaching requirements * the default case (heap allocation) ''must work out-of-the box'' * optionally a C++ standard conformant `Allocator` can be adapted * which works correct even in case this allocator is ''not a monostate'' * **essential requirement** is to pass an `AllocationCluster` reference directly * need a ''generic extension point'' to adapt to similar elaborate custom schemes __Note__: especially we want to create a direct collaboration between the allocation policy and the underlying allocator to allow support for a dedicate ''realloc operation''
2024-06-06 23:15:49 +02:00
};
Library: rearrange logic for trivial move detection ...still fighting to get the design of the `AllocationPolicy` settled to work well with `AllocationCluster` while also allowing to handle data types which are (not) trivially copyable. This changeset attempts to turn the logic round: now we capture an ''move exclusion flag'' and otherwise allow the Policy to decide on its own, based on the ''element type''
2024-06-08 21:58:04 +02:00
template<class I, class E>
using HeapOwn = AllocationPolicy<I, E, std::allocator>;
Library: work out adaptor solution for custom allocator ...turns out to be rather challenging, due to the far reaching requirements * the default case (heap allocation) ''must work out-of-the box'' * optionally a C++ standard conformant `Allocator` can be adapted * which works correct even in case this allocator is ''not a monostate'' * **essential requirement** is to pass an `AllocationCluster` reference directly * need a ''generic extension point'' to adapt to similar elaborate custom schemes __Note__: especially we want to create a direct collaboration between the allocation policy and the underlying allocator to allow support for a dedicate ''realloc operation''
2024-06-06 23:15:49 +02:00
Library: rearrange strategy code Parts of the decision logic for element handling was packaged as separate »strategy« class — but this turned out to be neither a real abstraction, nor configurable in any way. Thus it is better to simplify the structure and turn these type predicates into simple private member functions of the SeveralBuilder itself
2024-06-11 02:48:23 +02:00
}//(End)implementation details
Library: data layout for the new `Several` container - favour dynamic polymorphism - use additional memory for management data alongside the element allocation - encode a flag and a deleter pointer to enable ownership of the allocation - inherit base container privately into builder, so the build ends with a slice
2024-05-28 17:20:34 +02:00
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.
2024-05-12 19:05:50 +02:00
/**
* Wrap a vector holding objects of a subtype and
* provide array-like access using the interface type.
*/
Library: rearrange logic for trivial move detection ...still fighting to get the design of the `AllocationPolicy` settled to work well with `AllocationCluster` while also allowing to handle data types which are (not) trivially copyable. This changeset attempts to turn the logic round: now we capture an ''move exclusion flag'' and otherwise allow the Policy to decide on its own, based on the ''element type''
2024-06-08 21:58:04 +02:00
template<class I ///< Interface or base type visible on resulting Several<I>
,class E =I ///< a subclass element element type (relevant when not trivially movable and destructible)
,class POL =HeapOwn<I,E> ///< Allocator policy
Library: work out Skeleton for memory-handling strategy - the basic decision is to implement ''realloc'' similar to `std::vector` - however the situation is complicated by the desire to allow arbitrary element types - ⟹ must build a strategy based on the properties of the target type - the completely dynamic growth is only possibly for trivially-movable types - can introduce a dedicated ''element type'' though, and store a trampolin handler
2024-06-04 23:24:11 +02:00
>
Library: start design draft to replace `RefArray` Some decisions - use a single template with policy base - population via separate builder class - implemented similar to vector (start/end) - but able to hold larger (subclass) objects
2024-05-28 04:03:51 +02:00
class SeveralBuilder
Library: cover handling limits for virtual baseclass scenario building on the preceding analysis, we can now demonstrate that the container is initially able to grow, but looses this capability after accepting one element of unknown subclass type...
2024-06-12 17:59:56 +02:00
: private Several<I>
Library: sketch for a deleter trampoline for simple allocators this can be static
2024-06-06 18:41:07 +02:00
, util::MoveOnly
Library: data layout for the new `Several` container - favour dynamic polymorphism - use additional memory for management data alongside the element allocation - encode a flag and a deleter pointer to enable ownership of the allocation - inherit base container privately into builder, so the build ends with a slice
2024-05-28 17:20:34 +02:00
, POL
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.
2024-05-12 19:05:50 +02:00
{
Library: attempt to build a re-alloc on top of the new adapter ...which basically ''seems doable'' now, yet turns up several unsolved problems - need a way to handle excess storage for the raw allocation - generally should relocate all metadata into the ArrayBucket - mismatch at various APIs; must re-think where to pass size explicitly - unclear yet how and where to pass the actual element type to create
2024-06-07 19:04:06 +02:00
using Coll = Several<I>;
Library: draft skeleton of builder operations - create by forwarding allocator arguments to policy - builder-Op to append from iterator - decide to collapse the ArrayBucket class, since access is going through unsafe pointer arithmetic anyway
2024-05-28 18:52:01 +02:00
Library: rearrange strategy code Parts of the decision logic for element handling was packaged as separate »strategy« class — but this turned out to be neither a real abstraction, nor configurable in any way. Thus it is better to simplify the structure and turn these type predicates into simple private member functions of the SeveralBuilder itself
2024-06-11 02:48:23 +02:00
using Bucket = ArrayBucket<I>;
using Deleter = typename Bucket::Deleter;
Library: integrate strategy for acceptable element types Draft skeleton of the logic for element creation. This turns out to be a rather challenging piece of code, since we have to rely on logical reasoning about properties of the element types in order to decide if and how these elements can be emplaced, including the possibility to re-allocate and move existing data to a new location. - if we know the exact element type, we can handle any copyable or movable object - however, if the container is filled with a mixture of types, we can not re-allocate or grow dynamically, unless all data is trivially copyable (and can thus be handled through memmove) - moreover we must ensure the ability to invoke the proper destructor
2024-06-08 01:51:32 +02:00
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.
2024-05-12 19:05:50 +02:00
public:
Library: draft skeleton of builder operations - create by forwarding allocator arguments to policy - builder-Op to append from iterator - decide to collapse the ArrayBucket class, since access is going through unsafe pointer arithmetic anyway
2024-05-28 18:52:01 +02:00
SeveralBuilder() = default;
/** start Several build using a custom allocator */
template<typename...ARGS, typename = meta::enable_if<std::is_constructible<POL,ARGS...>>>
SeveralBuilder (ARGS&& ...alloInit)
: Several<I>{}
, POL{forward<ARGS> (alloInit)...}
{ }
Library: rearrange strategy code Parts of the decision logic for element handling was packaged as separate »strategy« class — but this turned out to be neither a real abstraction, nor configurable in any way. Thus it is better to simplify the structure and turn these type predicates into simple private member functions of the SeveralBuilder itself
2024-06-11 02:48:23 +02:00
/* ===== Builder API ===== */
Library: draft skeleton of builder operations - create by forwarding allocator arguments to policy - builder-Op to append from iterator - decide to collapse the ArrayBucket class, since access is going through unsafe pointer arithmetic anyway
2024-05-28 18:52:01 +02:00
SeveralBuilder&&
reserve (size_t cntElm)
{
Library: better alignment handling Elements maintained within the storage should be placed such as to comply with their alignment requirements; the element spacing thus must be increased to be a multiple of the given type's alignment. This solution works in most common cases, where the alignement is not larger as the platform's bus width (typically 64bit); but for ''over-aligned types'' this scheme may still generate wrong object start positions (a completely correct solution would require to add a fixed offset to the beginning of the storage array and also to capture the alignment requirements during population and to re-check for each new type.
2024-06-11 00:57:24 +02:00
adjustStorage (cntElm, reqSiz<E>());
Library: draft skeleton of builder operations - create by forwarding allocator arguments to policy - builder-Op to append from iterator - decide to collapse the ArrayBucket class, since access is going through unsafe pointer arithmetic anyway
2024-05-28 18:52:01 +02:00
return move(*this);
}
Library: builder to add heterogeneous elements ...turns out that we must ensure to pass a plain "object" type to the standard allocator framework (no const, no references). Here, ''object in C++ terminology'' means a scalar or record type, but no functor, no references and no void,
2024-06-11 23:22:00 +02:00
template<typename VAL, typename...VALS>
SeveralBuilder&&
append (VAL&& val, VALS&& ...vals)
{
emplace<VAL> (forward<VAL> (val));
if constexpr (0 < sizeof...(VALS))
return append (forward<VALS> (vals)...);
else
return move(*this);
}
Library: draft skeleton of builder operations - create by forwarding allocator arguments to policy - builder-Op to append from iterator - decide to collapse the ArrayBucket class, since access is going through unsafe pointer arithmetic anyway
2024-05-28 18:52:01 +02:00
template<class IT>
SeveralBuilder&&
appendAll (IT&& data)
{
Library: integrate strategy for acceptable element types Draft skeleton of the logic for element creation. This turns out to be a rather challenging piece of code, since we have to rely on logical reasoning about properties of the element types in order to decide if and how these elements can be emplaced, including the possibility to re-allocate and move existing data to a new location. - if we know the exact element type, we can handle any copyable or movable object - however, if the container is filled with a mixture of types, we can not re-allocate or grow dynamically, unless all data is trivially copyable (and can thus be handled through memmove) - moreover we must ensure the ability to invoke the proper destructor
2024-06-08 01:51:32 +02:00
explore(data).foreach ([this](auto it){ emplaceCopy(it); });
Library: draft skeleton of builder operations - create by forwarding allocator arguments to policy - builder-Op to append from iterator - decide to collapse the ArrayBucket class, since access is going through unsafe pointer arithmetic anyway
2024-05-28 18:52:01 +02:00
return move(*this);
}
Library: elaborate `SeveralBuilder` operations Consider what (not) to support. Notably I decided ''not to support'' moving out of an iterator, since doing so would contradict the fundamental assumptions of the »Lumiera Forward Iterator« Concept. Start verifying some variations of element placement, still focussing on the simple cases
2024-06-11 18:23:48 +02:00
template<class X>
SeveralBuilder&&
appendAll (std::initializer_list<X> ili)
{
using Val = typename meta::Strip<X>::TypeReferred;
for (Val const& x : ili)
emplaceNewElm<Val> (x);
return move(*this);
}
template<typename...ARGS>
SeveralBuilder&&
fillElm (size_t cntNew, ARGS&& ...args)
{
for ( ; 0<cntNew; --cntNew)
Library: investigate case with known element type - the test-dummy objects need a `noexcept` move ctor - **bug** here: need an explicit check to prevent other types than the known element type from ''sneaking in''
2024-06-12 03:23:20 +02:00
emplaceNewElm<E> (forward<ARGS> (args)...);
Library: elaborate `SeveralBuilder` operations Consider what (not) to support. Notably I decided ''not to support'' moving out of an iterator, since doing so would contradict the fundamental assumptions of the »Lumiera Forward Iterator« Concept. Start verifying some variations of element placement, still focussing on the simple cases
2024-06-11 18:23:48 +02:00
return move(*this);
}
template<class TY, typename...ARGS>
SeveralBuilder&&
emplace (ARGS&& ...args)
{
Library: builder to add heterogeneous elements ...turns out that we must ensure to pass a plain "object" type to the standard allocator framework (no const, no references). Here, ''object in C++ terminology'' means a scalar or record type, but no functor, no references and no void,
2024-06-11 23:22:00 +02:00
using Val = typename meta::Strip<TY>::TypeReferred;
Library: elaborate `SeveralBuilder` operations Consider what (not) to support. Notably I decided ''not to support'' moving out of an iterator, since doing so would contradict the fundamental assumptions of the »Lumiera Forward Iterator« Concept. Start verifying some variations of element placement, still focussing on the simple cases
2024-06-11 18:23:48 +02:00
emplaceNewElm<Val> (forward<ARGS> (args)...);
return move(*this);
}
Library: rearrange strategy code Parts of the decision logic for element handling was packaged as separate »strategy« class — but this turned out to be neither a real abstraction, nor configurable in any way. Thus it is better to simplify the structure and turn these type predicates into simple private member functions of the SeveralBuilder itself
2024-06-11 02:48:23 +02:00
/**
* Terminal Builder: complete and lock the collection contents.
* @note the SeveralBuilder is sliced away, effectively
* returning only the pointer to the ArrayBucket.
*/
Library: start design draft to replace `RefArray` Some decisions - use a single template with policy base - population via separate builder class - implemented similar to vector (start/end) - but able to hold larger (subclass) objects
2024-05-28 04:03:51 +02:00
Several<I>
build()
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.
2024-05-12 19:05:50 +02:00
{
Library: implement access to storage and subscript ...not sure if this approach works out OK, since we can not make a safe downcast to a size known at runtime
2024-05-28 18:07:08 +02:00
return move (*this);
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.
2024-05-12 19:05:50 +02:00
}
Library: draft skeleton of builder operations - create by forwarding allocator arguments to policy - builder-Op to append from iterator - decide to collapse the ArrayBucket class, since access is going through unsafe pointer arithmetic anyway
2024-05-28 18:52:01 +02:00
Library: elaborate `SeveralBuilder` operations Consider what (not) to support. Notably I decided ''not to support'' moving out of an iterator, since doing so would contradict the fundamental assumptions of the »Lumiera Forward Iterator« Concept. Start verifying some variations of element placement, still focussing on the simple cases
2024-06-11 18:23:48 +02:00
size_t size() const { return Coll::size(); }
bool empty() const { return Coll::empty();}
Library: draft skeleton of builder operations - create by forwarding allocator arguments to policy - builder-Op to append from iterator - decide to collapse the ArrayBucket class, since access is going through unsafe pointer arithmetic anyway
2024-05-28 18:52:01 +02:00
private:
Library: integrate storage-management logic Parts of this logic were first coded down in the `realloc` template method, where it did not really belong; thus reintegrate similar logic one level above, in the SeveralBuilder::adjustStorage(). Moreover, for performance reasons, always start with an initial chunk, similar to what `std::vector` does...
2024-06-08 23:59:47 +02:00
template<class IT>
void
emplaceCopy (IT& dataSrc)
{
Library: elaborate `SeveralBuilder` operations Consider what (not) to support. Notably I decided ''not to support'' moving out of an iterator, since doing so would contradict the fundamental assumptions of the »Lumiera Forward Iterator« Concept. Start verifying some variations of element placement, still focussing on the simple cases
2024-06-11 18:23:48 +02:00
using Val = typename IT::value_type;
emplaceNewElm<Val> (*dataSrc);
Library: integrate storage-management logic Parts of this logic were first coded down in the `realloc` template method, where it did not really belong; thus reintegrate similar logic one level above, in the SeveralBuilder::adjustStorage(). Moreover, for performance reasons, always start with an initial chunk, similar to what `std::vector` does...
2024-06-08 23:59:47 +02:00
}
template<class TY, typename...ARGS>
void
Library: elaborate `SeveralBuilder` operations Consider what (not) to support. Notably I decided ''not to support'' moving out of an iterator, since doing so would contradict the fundamental assumptions of the »Lumiera Forward Iterator« Concept. Start verifying some variations of element placement, still focussing on the simple cases
2024-06-11 18:23:48 +02:00
emplaceNewElm (ARGS&& ...args)
Library: integrate storage-management logic Parts of this logic were first coded down in the `realloc` template method, where it did not really belong; thus reintegrate similar logic one level above, in the SeveralBuilder::adjustStorage(). Moreover, for performance reasons, always start with an initial chunk, similar to what `std::vector` does...
2024-06-08 23:59:47 +02:00
{
Library: builder to add heterogeneous elements ...turns out that we must ensure to pass a plain "object" type to the standard allocator framework (no const, no references). Here, ''object in C++ terminology'' means a scalar or record type, but no functor, no references and no void,
2024-06-11 23:22:00 +02:00
static_assert (is_object_v<TY> and not (is_const_v<TY> or is_volatile_v<TY>));
Library: integrate storage-management logic Parts of this logic were first coded down in the `realloc` template method, where it did not really belong; thus reintegrate similar logic one level above, in the SeveralBuilder::adjustStorage(). Moreover, for performance reasons, always start with an initial chunk, similar to what `std::vector` does...
2024-06-08 23:59:47 +02:00
// mark when target type is not trivially movable
Library: rearrange strategy code Parts of the decision logic for element handling was packaged as separate »strategy« class — but this turned out to be neither a real abstraction, nor configurable in any way. Thus it is better to simplify the structure and turn these type predicates into simple private member functions of the SeveralBuilder itself
2024-06-11 02:48:23 +02:00
probeMoveCapability<TY>();
Library: integrate storage-management logic Parts of this logic were first coded down in the `realloc` template method, where it did not really belong; thus reintegrate similar logic one level above, in the SeveralBuilder::adjustStorage(). Moreover, for performance reasons, always start with an initial chunk, similar to what `std::vector` does...
2024-06-08 23:59:47 +02:00
// ensure sufficient element capacity or the ability to adapt element spread
Library: rearrange strategy code Parts of the decision logic for element handling was packaged as separate »strategy« class — but this turned out to be neither a real abstraction, nor configurable in any way. Thus it is better to simplify the structure and turn these type predicates into simple private member functions of the SeveralBuilder itself
2024-06-11 02:48:23 +02:00
if (Coll::spread() < reqSiz<TY>() and not (Coll::empty() or canWildMove()))
Library: integrate storage-management logic Parts of this logic were first coded down in the `realloc` template method, where it did not really belong; thus reintegrate similar logic one level above, in the SeveralBuilder::adjustStorage(). Moreover, for performance reasons, always start with an initial chunk, similar to what `std::vector` does...
2024-06-08 23:59:47 +02:00
throw err::Invalid{_Fmt{"Unable to place element of type %s (size=%d)"
Library: cover handling limits for virtual baseclass scenario building on the preceding analysis, we can now demonstrate that the container is initially able to grow, but looses this capability after accepting one element of unknown subclass type...
2024-06-12 17:59:56 +02:00
"into Several-container for element size %d."}
Library: better alignment handling Elements maintained within the storage should be placed such as to comply with their alignment requirements; the element spacing thus must be increased to be a multiple of the given type's alignment. This solution works in most common cases, where the alignement is not larger as the platform's bus width (typically 64bit); but for ''over-aligned types'' this scheme may still generate wrong object start positions (a completely correct solution would require to add a fixed offset to the beginning of the storage array and also to capture the alignment requirements during population and to re-check for each new type.
2024-06-11 00:57:24 +02:00
% util::typeStr<TY>() % reqSiz<TY>() % Coll::spread()};
Library: integrate storage-management logic Parts of this logic were first coded down in the `realloc` template method, where it did not really belong; thus reintegrate similar logic one level above, in the SeveralBuilder::adjustStorage(). Moreover, for performance reasons, always start with an initial chunk, similar to what `std::vector` does...
2024-06-08 23:59:47 +02:00
Library: work out a solution how to store a Deleter functor After some fruitless attempts, I settled for using std::function directly, in order to establish a working baseline of this (tremendously complicated) allocation logic. Storing a std::function in the ArrayBucket is certainly wasteful (it costs 4 »slots« of memory), but has the upside that it handles all those tricky corner cases magically; notably the functor can be stored completely inline in the most relevant case where the allocator is a monostate; moreover we bind a lambda, which can be optimised very effectively, so that in the simplest case there will be only the single indirection through the ''invoker''. This **completes the code path for a simple usage cycle** 🠲 ''and hooray ... the test crashes with a double-free''
2024-06-09 23:45:24 +02:00
// ensure sufficient storage or verify the ability to re-allocate
Library: elaborate `SeveralBuilder` operations Consider what (not) to support. Notably I decided ''not to support'' moving out of an iterator, since doing so would contradict the fundamental assumptions of the »Lumiera Forward Iterator« Concept. Start verifying some variations of element placement, still focussing on the simple cases
2024-06-11 18:23:48 +02:00
if (not (Coll::empty() or Coll::hasReserve(reqSiz<TY>())
Library: better alignment handling Elements maintained within the storage should be placed such as to comply with their alignment requirements; the element spacing thus must be increased to be a multiple of the given type's alignment. This solution works in most common cases, where the alignement is not larger as the platform's bus width (typically 64bit); but for ''over-aligned types'' this scheme may still generate wrong object start positions (a completely correct solution would require to add a fixed offset to the beginning of the storage array and also to capture the alignment requirements during population and to re-check for each new type.
2024-06-11 00:57:24 +02:00
or POL::canExpand(reqSiz<TY>())
Library: rearrange strategy code Parts of the decision logic for element handling was packaged as separate »strategy« class — but this turned out to be neither a real abstraction, nor configurable in any way. Thus it is better to simplify the structure and turn these type predicates into simple private member functions of the SeveralBuilder itself
2024-06-11 02:48:23 +02:00
or canDynGrow()))
Library: cover handling limits for virtual baseclass scenario building on the preceding analysis, we can now demonstrate that the container is initially able to grow, but looses this capability after accepting one element of unknown subclass type...
2024-06-12 17:59:56 +02:00
throw err::Invalid{_Fmt{"Several-container is unable to accommodate further element of type %s; "
"storage reserve (%s bytes) exhausted and unable to move elements "
"of mixed unknown detail type, which are not trivially movable." }
% util::typeStr<TY>() % Coll::storageBuffSiz()};
Library: work out a solution how to store a Deleter functor After some fruitless attempts, I settled for using std::function directly, in order to establish a working baseline of this (tremendously complicated) allocation logic. Storing a std::function in the ArrayBucket is certainly wasteful (it costs 4 »slots« of memory), but has the upside that it handles all those tricky corner cases magically; notably the functor can be stored completely inline in the most relevant case where the allocator is a monostate; moreover we bind a lambda, which can be optimised very effectively, so that in the simplest case there will be only the single indirection through the ''invoker''. This **completes the code path for a simple usage cycle** 🠲 ''and hooray ... the test crashes with a double-free''
2024-06-09 23:45:24 +02:00
Library: better alignment handling Elements maintained within the storage should be placed such as to comply with their alignment requirements; the element spacing thus must be increased to be a multiple of the given type's alignment. This solution works in most common cases, where the alignement is not larger as the platform's bus width (typically 64bit); but for ''over-aligned types'' this scheme may still generate wrong object start positions (a completely correct solution would require to add a fixed offset to the beginning of the storage array and also to capture the alignment requirements during population and to re-check for each new type.
2024-06-11 00:57:24 +02:00
size_t elmSiz = reqSiz<TY>();
Library: integrate storage-management logic Parts of this logic were first coded down in the `realloc` template method, where it did not really belong; thus reintegrate similar logic one level above, in the SeveralBuilder::adjustStorage(). Moreover, for performance reasons, always start with an initial chunk, similar to what `std::vector` does...
2024-06-08 23:59:47 +02:00
size_t newPos = Coll::size();
size_t newCnt = Coll::empty()? INITIAL_ELM_CNT : newPos+1;
adjustStorage (newCnt, max (elmSiz, Coll::spread()));
Library: logic to select a suitable deleter - ensure the ''deleter function'' is invoked - care for proper ''deleter'' setup in case of exception while copying - need to »lock-in« on one specific kind of ''destructor invocation scheme,'' since we do not keep track of individual concrete element types
2024-06-09 17:19:40 +02:00
ENSURE (Coll::data_);
Library: work out a solution how to store a Deleter functor After some fruitless attempts, I settled for using std::function directly, in order to establish a working baseline of this (tremendously complicated) allocation logic. Storing a std::function in the ArrayBucket is certainly wasteful (it costs 4 »slots« of memory), but has the upside that it handles all those tricky corner cases magically; notably the functor can be stored completely inline in the most relevant case where the allocator is a monostate; moreover we bind a lambda, which can be optimised very effectively, so that in the simplest case there will be only the single indirection through the ''invoker''. This **completes the code path for a simple usage cycle** 🠲 ''and hooray ... the test crashes with a double-free''
2024-06-09 23:45:24 +02:00
ensureDeleter<TY>();
Library: integrate storage-management logic Parts of this logic were first coded down in the `realloc` template method, where it did not really belong; thus reintegrate similar logic one level above, in the SeveralBuilder::adjustStorage(). Moreover, for performance reasons, always start with an initial chunk, similar to what `std::vector` does...
2024-06-08 23:59:47 +02:00
POL::template createAt<TY> (Coll::data_, newPos, forward<ARGS> (args)...);
Library: work out a solution how to store a Deleter functor After some fruitless attempts, I settled for using std::function directly, in order to establish a working baseline of this (tremendously complicated) allocation logic. Storing a std::function in the ArrayBucket is certainly wasteful (it costs 4 »slots« of memory), but has the upside that it handles all those tricky corner cases magically; notably the functor can be stored completely inline in the most relevant case where the allocator is a monostate; moreover we bind a lambda, which can be optimised very effectively, so that in the simplest case there will be only the single indirection through the ''invoker''. This **completes the code path for a simple usage cycle** 🠲 ''and hooray ... the test crashes with a double-free''
2024-06-09 23:45:24 +02:00
Coll::data_->cnt = newPos+1;
}
Library: cover handling limits for virtual baseclass scenario building on the preceding analysis, we can now demonstrate that the container is initially able to grow, but looses this capability after accepting one element of unknown subclass type...
2024-06-12 17:59:56 +02:00
/** ensure clean-up can be handled properly.
* @throw err::Invalid when \a TY requires a different style
* of deleter than was established for this instance */
Library: work out a solution how to store a Deleter functor After some fruitless attempts, I settled for using std::function directly, in order to establish a working baseline of this (tremendously complicated) allocation logic. Storing a std::function in the ArrayBucket is certainly wasteful (it costs 4 »slots« of memory), but has the upside that it handles all those tricky corner cases magically; notably the functor can be stored completely inline in the most relevant case where the allocator is a monostate; moreover we bind a lambda, which can be optimised very effectively, so that in the simplest case there will be only the single indirection through the ''invoker''. This **completes the code path for a simple usage cycle** 🠲 ''and hooray ... the test crashes with a double-free''
2024-06-09 23:45:24 +02:00
template<class TY>
void
ensureDeleter()
{
Library: rearrange strategy code Parts of the decision logic for element handling was packaged as separate »strategy« class — but this turned out to be neither a real abstraction, nor configurable in any way. Thus it is better to simplify the structure and turn these type predicates into simple private member functions of the SeveralBuilder itself
2024-06-11 02:48:23 +02:00
Deleter deleterFunctor = selectDestructor<TY>();
Library: work out a solution how to store a Deleter functor After some fruitless attempts, I settled for using std::function directly, in order to establish a working baseline of this (tremendously complicated) allocation logic. Storing a std::function in the ArrayBucket is certainly wasteful (it costs 4 »slots« of memory), but has the upside that it handles all those tricky corner cases magically; notably the functor can be stored completely inline in the most relevant case where the allocator is a monostate; moreover we bind a lambda, which can be optimised very effectively, so that in the simplest case there will be only the single indirection through the ''invoker''. This **completes the code path for a simple usage cycle** 🠲 ''and hooray ... the test crashes with a double-free''
2024-06-09 23:45:24 +02:00
if (Coll::data_->deleter) return;
Coll::data_->deleter = deleterFunctor;
Library: integrate storage-management logic Parts of this logic were first coded down in the `realloc` template method, where it did not really belong; thus reintegrate similar logic one level above, in the SeveralBuilder::adjustStorage(). Moreover, for performance reasons, always start with an initial chunk, similar to what `std::vector` does...
2024-06-08 23:59:47 +02:00
}
Library: draft skeleton of builder operations - create by forwarding allocator arguments to policy - builder-Op to append from iterator - decide to collapse the ArrayBucket class, since access is going through unsafe pointer arithmetic anyway
2024-05-28 18:52:01 +02:00
void
adjustStorage (size_t cnt, size_t spread)
{
Library: attempt to build a re-alloc on top of the new adapter ...which basically ''seems doable'' now, yet turns up several unsolved problems - need a way to handle excess storage for the raw allocation - generally should relocate all metadata into the ArrayBucket - mismatch at various APIs; must re-think where to pass size explicitly - unclear yet how and where to pass the actual element type to create
2024-06-07 19:04:06 +02:00
size_t demand{cnt*spread};
Library: cover handling limits for virtual baseclass scenario building on the preceding analysis, we can now demonstrate that the container is initially able to grow, but looses this capability after accepting one element of unknown subclass type...
2024-06-12 17:59:56 +02:00
size_t buffSiz{Coll::storageBuffSiz()};
Library: integrate storage-management logic Parts of this logic were first coded down in the `realloc` template method, where it did not really belong; thus reintegrate similar logic one level above, in the SeveralBuilder::adjustStorage(). Moreover, for performance reasons, always start with an initial chunk, similar to what `std::vector` does...
2024-06-08 23:59:47 +02:00
if (demand == buffSiz)
return;
if (demand > buffSiz)
{// grow into exponentially expanded new allocation
size_t safetyLim = LUMIERA_MAX_ORDINAL_NUMBER * Coll::spread();
size_t expandAlloc = min (safetyLim
,max (2*buffSiz, demand));
if (expandAlloc < demand)
throw err::State{_Fmt{"Storage expansion for Several-collection "
"exceeds safety limit of %d bytes"} % safetyLim
,LERR_(SAFETY_LIMIT)};
// allocate new storage block...
size_t newCnt = expandAlloc / spread;
if (newCnt * spread < expandAlloc) ++newCnt;
Coll::data_ = POL::realloc (Coll::data_, newCnt,spread);
}
Library: attempt to build a re-alloc on top of the new adapter ...which basically ''seems doable'' now, yet turns up several unsolved problems - need a way to handle excess storage for the raw allocation - generally should relocate all metadata into the ArrayBucket - mismatch at various APIs; must re-think where to pass size explicitly - unclear yet how and where to pass the actual element type to create
2024-06-07 19:04:06 +02:00
ENSURE (Coll::data_);
Library: rearrange strategy code Parts of the decision logic for element handling was packaged as separate »strategy« class — but this turned out to be neither a real abstraction, nor configurable in any way. Thus it is better to simplify the structure and turn these type predicates into simple private member functions of the SeveralBuilder itself
2024-06-11 02:48:23 +02:00
if (canWildMove() and spread != Coll::spread())
Library: draft memory rearrangements not clear yet how to handle the classical "realloc" situation
2024-05-29 01:01:16 +02:00
adjustSpread (spread);
Library: attempt to build a re-alloc on top of the new adapter ...which basically ''seems doable'' now, yet turns up several unsolved problems - need a way to handle excess storage for the raw allocation - generally should relocate all metadata into the ArrayBucket - mismatch at various APIs; must re-think where to pass size explicitly - unclear yet how and where to pass the actual element type to create
2024-06-07 19:04:06 +02:00
}
void
fitStorage()
{
Library: rearrange strategy code Parts of the decision logic for element handling was packaged as separate »strategy« class — but this turned out to be neither a real abstraction, nor configurable in any way. Thus it is better to simplify the structure and turn these type predicates into simple private member functions of the SeveralBuilder itself
2024-06-11 02:48:23 +02:00
if (not Coll::data)
Library: integrate storage-management logic Parts of this logic were first coded down in the `realloc` template method, where it did not really belong; thus reintegrate similar logic one level above, in the SeveralBuilder::adjustStorage(). Moreover, for performance reasons, always start with an initial chunk, similar to what `std::vector` does...
2024-06-08 23:59:47 +02:00
return;
Library: rearrange strategy code Parts of the decision logic for element handling was packaged as separate »strategy« class — but this turned out to be neither a real abstraction, nor configurable in any way. Thus it is better to simplify the structure and turn these type predicates into simple private member functions of the SeveralBuilder itself
2024-06-11 02:48:23 +02:00
if (not canDynGrow())
throw err::Invalid{"Unable to shrink storage for Several-collection, "
"since at least one element can not be moved."};
Library: integrate storage-management logic Parts of this logic were first coded down in the `realloc` template method, where it did not really belong; thus reintegrate similar logic one level above, in the SeveralBuilder::adjustStorage(). Moreover, for performance reasons, always start with an initial chunk, similar to what `std::vector` does...
2024-06-08 23:59:47 +02:00
Coll::data_ = POL::realloc (Coll::data_, Coll::size(), Coll::spread());
Library: draft memory rearrangements not clear yet how to handle the classical "realloc" situation
2024-05-29 01:01:16 +02:00
}
/** move existing data to accommodate spread */
void
adjustSpread (size_t newSpread)
{
Library: attempt to build a re-alloc on top of the new adapter ...which basically ''seems doable'' now, yet turns up several unsolved problems - need a way to handle excess storage for the raw allocation - generally should relocate all metadata into the ArrayBucket - mismatch at various APIs; must re-think where to pass size explicitly - unclear yet how and where to pass the actual element type to create
2024-06-07 19:04:06 +02:00
REQUIRE (Coll::data_);
Library: cover handling limits for virtual baseclass scenario building on the preceding analysis, we can now demonstrate that the container is initially able to grow, but looses this capability after accepting one element of unknown subclass type...
2024-06-12 17:59:56 +02:00
REQUIRE (newSpread * Coll::size() <= Coll::storageBuffSiz());
Library: switch rest of implementation ...and remove now obsolete metadata fields in the collection and builder classes
2024-06-07 23:02:51 +02:00
size_t oldSpread = Coll::spread();
Library: draft memory rearrangements not clear yet how to handle the classical "realloc" situation
2024-05-29 01:01:16 +02:00
if (newSpread > oldSpread)
// need to spread out
Library: rearrange storage layout In-depth analysis of storage management revealed a misconception with respect to possible storage optimisations, requiring more metadata fields to handle all corner cases correctly. It seems prudent to avoid any but the most obvious optimisations and wait for real-world usage for a better understanding of the prevalent access patterns. However, in preparation for any future optimisations, all access coordination and storage metadata is now relocated into the `ArrayBucket`, and thus resides within the managed allocation, allowing for localised layout optimisations. To place this into context: the expected prevalent use case is for the »Render Nodes Network«, which relies on `AllocationCluster` for storage management; most nodes will have only a single predecessor or successor, leading to a large number of lib::Several intsances populated with a single data element. In such a scenario, it is indeed rather wasteful to allocate four »slot« of metadata for each container instance; even more so since most of this metadata is not even required in such a scenario.
2024-06-07 22:23:06 +02:00
for (size_t i=Coll::size()-1; 0<i; --i)
Library: draft memory rearrangements not clear yet how to handle the classical "realloc" situation
2024-05-29 01:01:16 +02:00
shiftStorage (i, oldSpread, newSpread);
else
// attempt to condense spread
Library: rearrange storage layout In-depth analysis of storage management revealed a misconception with respect to possible storage optimisations, requiring more metadata fields to handle all corner cases correctly. It seems prudent to avoid any but the most obvious optimisations and wait for real-world usage for a better understanding of the prevalent access patterns. However, in preparation for any future optimisations, all access coordination and storage metadata is now relocated into the `ArrayBucket`, and thus resides within the managed allocation, allowing for localised layout optimisations. To place this into context: the expected prevalent use case is for the »Render Nodes Network«, which relies on `AllocationCluster` for storage management; most nodes will have only a single predecessor or successor, leading to a large number of lib::Several intsances populated with a single data element. In such a scenario, it is indeed rather wasteful to allocate four »slot« of metadata for each container instance; even more so since most of this metadata is not even required in such a scenario.
2024-06-07 22:23:06 +02:00
for (size_t i=1; i<Coll::size(); ++i)
Library: draft memory rearrangements not clear yet how to handle the classical "realloc" situation
2024-05-29 01:01:16 +02:00
shiftStorage (i, oldSpread, newSpread);
// data elements now spaced by new spread
Library: attempt to build a re-alloc on top of the new adapter ...which basically ''seems doable'' now, yet turns up several unsolved problems - need a way to handle excess storage for the raw allocation - generally should relocate all metadata into the ArrayBucket - mismatch at various APIs; must re-think where to pass size explicitly - unclear yet how and where to pass the actual element type to create
2024-06-07 19:04:06 +02:00
Coll::data_->spread = newSpread;
Library: draft memory rearrangements not clear yet how to handle the classical "realloc" situation
2024-05-29 01:01:16 +02:00
}
void
shiftStorage (size_t idx, size_t oldSpread, size_t newSpread)
{
REQUIRE (idx);
REQUIRE (oldSpread);
REQUIRE (newSpread);
Library: attempt to build a re-alloc on top of the new adapter ...which basically ''seems doable'' now, yet turns up several unsolved problems - need a way to handle excess storage for the raw allocation - generally should relocate all metadata into the ArrayBucket - mismatch at various APIs; must re-think where to pass size explicitly - unclear yet how and where to pass the actual element type to create
2024-06-07 19:04:06 +02:00
REQUIRE (Coll::data_);
byte* oldPos = Coll::data_->storage;
Library: draft memory rearrangements not clear yet how to handle the classical "realloc" situation
2024-05-29 01:01:16 +02:00
byte* newPos = oldPos;
oldPos += idx * oldSpread;
newPos += idx * newSpread;
std::memmove (newPos, oldPos, util::min (oldSpread,newSpread));
Library: draft skeleton of builder operations - create by forwarding allocator arguments to policy - builder-Op to append from iterator - decide to collapse the ArrayBucket class, since access is going through unsafe pointer arithmetic anyway
2024-05-28 18:52:01 +02:00
}
Library: rearrange strategy code Parts of the decision logic for element handling was packaged as separate »strategy« class — but this turned out to be neither a real abstraction, nor configurable in any way. Thus it is better to simplify the structure and turn these type predicates into simple private member functions of the SeveralBuilder itself
2024-06-11 02:48:23 +02:00
/* ==== Logic do decide about possible element handling ==== */
enum DestructionMethod{ UNKNOWN
, TRIVIAL
, ELEMENT
, VIRTUAL
};
static Literal
render (DestructionMethod m)
{
switch (m)
{
case TRIVIAL: return "trivial";
case ELEMENT: return "fixed-element-type";
case VIRTUAL: return "virtual-baseclass";
default:
throw err::Logic{"unknown DestructionMethod"};
}
}
DestructionMethod destructor{UNKNOWN};
bool lock_move{false};
/**
* Select a suitable method for invoking the element destructors
* and build a λ-object to be stored as deleter function alongside
* with the data; this includes a _copy_ of the embedded allocator,
* which in many cases is a monostate empty base class.
* @note this collection is _primed_ by the first element added,
* causing to lock into one of the possible destructor schemes;
* the reason is, we do not retain the information of the individual
* element types and thus we must employ one coherent scheme for all.
*/
template<typename TY>
Deleter
Library: reassess logic to reject some types for existing container `lib::Several` is designed to be highly adaptable, allowing for several quite distinct usage styles. On the downside, this requires to perform some checks at runtime only, since the ability to handle some element depends on specific circumstances. This is a notable difference to `std::vector`, which is simply not capable of handling ''non-copyable'' types, even if given an up-front memory reservation. The last test case provided with the previous changeset did not trigger an exception, but closer investigation revealed that this is correct, since in this specific situation the container can accept this object type, thereby just loosing the ability to move-relocate further objects. A slightly re-arranged test scenario can be used to demonstrate this fine point.
2024-06-12 17:07:55 +02:00
selectDestructor()
Library: rearrange strategy code Parts of the decision logic for element handling was packaged as separate »strategy« class — but this turned out to be neither a real abstraction, nor configurable in any way. Thus it is better to simplify the structure and turn these type predicates into simple private member functions of the SeveralBuilder itself
2024-06-11 02:48:23 +02:00
{
typename POL::Fac& factory(*this);
if (is_Subclass<TY,I>() and has_virtual_destructor_v<I>)
{
__ensureMark<TY> (VIRTUAL);
return [factory](ArrayBucket<I>* bucket){ unConst(factory).template destroy<I> (bucket); };
}
if (is_trivially_destructible_v<TY>)
{
__ensureMark<TY> (TRIVIAL);
return [factory](ArrayBucket<I>* bucket){ unConst(factory).template destroy<TY> (bucket); };
}
if (is_same_v<TY,E> and is_Subclass<E,I>())
{
__ensureMark<TY> (ELEMENT);
return [factory](ArrayBucket<I>* bucket){ unConst(factory).template destroy<E> (bucket); };
}
throw err::Invalid{_Fmt{"Unsupported kind of destructor for element type %s."}
% util::typeStr<TY>()};
}
template<typename TY>
void
Library: some coverage for rejected type placements The `SeveralBuilder` is very flexible with respect to added elements, but it will investigate the provided type information and reject any further build operation that can not be carried out safely.
2024-06-12 00:57:57 +02:00
__ensureMark (DestructionMethod requiredKind)
Library: rearrange strategy code Parts of the decision logic for element handling was packaged as separate »strategy« class — but this turned out to be neither a real abstraction, nor configurable in any way. Thus it is better to simplify the structure and turn these type predicates into simple private member functions of the SeveralBuilder itself
2024-06-11 02:48:23 +02:00
{
Library: some coverage for rejected type placements The `SeveralBuilder` is very flexible with respect to added elements, but it will investigate the provided type information and reject any further build operation that can not be carried out safely.
2024-06-12 00:57:57 +02:00
if (destructor != UNKNOWN and destructor != requiredKind)
throw err::Invalid{_Fmt{"Unable to handle (%s-)destructor for element type %s, "
"since this container has been primed to use %s-destructors."}
% render(requiredKind)
% util::typeStr<TY>()
% render(destructor)};
destructor = requiredKind;
Library: rearrange strategy code Parts of the decision logic for element handling was packaged as separate »strategy« class — but this turned out to be neither a real abstraction, nor configurable in any way. Thus it is better to simplify the structure and turn these type predicates into simple private member functions of the SeveralBuilder itself
2024-06-11 02:48:23 +02:00
}
/** mark that we're about to accept an otherwise unknown type,
* which can not be trivially moved. This irrevocably disables
* relocations by low-level `memove` for this container instance */
template<typename TY>
void
probeMoveCapability()
{
if (not (is_same_v<TY,E> or is_trivially_copyable_v<TY>))
lock_move = true;
}
bool
canWildMove()
{
return is_trivially_copyable_v<E> and not lock_move;
}
bool
canDynGrow()
{
return not lock_move;
}
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.
2024-05-12 19:05:50 +02:00
};
Library: draft skeleton of builder operations - create by forwarding allocator arguments to policy - builder-Op to append from iterator - decide to collapse the ArrayBucket class, since access is going through unsafe pointer arithmetic anyway
2024-05-28 18:52:01 +02:00
Library: start design draft to replace `RefArray` Some decisions - use a single template with policy base - population via separate builder class - implemented similar to vector (start/end) - but able to hold larger (subclass) objects
2024-05-28 04:03:51 +02:00
template<typename X>
SeveralBuilder<X>
makeSeveral (std::initializer_list<X> ili)
{
Library: draft skeleton of builder operations - create by forwarding allocator arguments to policy - builder-Op to append from iterator - decide to collapse the ArrayBucket class, since access is going through unsafe pointer arithmetic anyway
2024-05-28 18:52:01 +02:00
return SeveralBuilder<X>{}
.reserve (ili.size())
.appendAll (ili);
Library: start design draft to replace `RefArray` Some decisions - use a single template with policy base - population via separate builder class - implemented similar to vector (start/end) - but able to hold larger (subclass) objects
2024-05-28 04:03:51 +02:00
}
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.
2024-05-12 19:05:50 +02:00
Library: test coverage for some ''special'' builder usages
2024-06-11 23:53:38 +02:00
template<typename I, typename E =I>
SeveralBuilder<I,E>
makeSeveral()
{
return SeveralBuilder<I,E>{};
}
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.
2024-05-12 19:05:50 +02:00
} // namespace lib
#endif /*LIB_SEVERAL_BUILDER_H*/
Reference in a new issue Copy permalink