Invocation: develop a concept for handling parameter data
...as part of the rendering process, executed on top of the
low-level-model (Render Node network) as conceived thus far.
Parameter handling could be ''encoded'' into render nodes altogether,
or, at the other extreme, an explicit parameter handling could be specified
as part of the Render Node execution. As both extremes will lead to some
unfavourable consequences, I am aiming at a middle ground: largely, the
''automation computation'' will be encoded and hidden within the network,
implying that this topic remains to be addressed as part of defining
the Builder semantics and implementation. Yet in part the required
processing structure can be foreseen at an abstract level, and thus
the essential primitive operations are specified explicitly as part
of the Render Node definition. Notably the ''standard Weaving Pattern''
will include a ''parameter tuple'' into each `FeedManifold` and require
a binding function, which accepts this tuple as first argument.
Moreover — at implementation level, a library facility must be provided
to support handling of ''arbitrary heterogeneous data values'' embedded
directly into stack frame memory, together with a type-safe compile-time
overlay, which allows the builder to embed specific ''accessor handles''
into functor bindings, even while the actual storage location is not
yet known at that time (obviously, as being located on the stack).
__Note__: a recurring topic is how to return descriptor objects from builder functions; for this purpose, I am adjusting the semantics of `lib/nocopy.hpp` to be more specific...
2024-12-09 21:55:48 +01:00
|
|
|
|
/*
|
|
|
|
|
|
HeteroData(Test) - verify maintaining chained heterogeneous data in local storage
|
|
|
|
|
|
|
|
|
|
|
|
Copyright (C)
|
|
|
|
|
|
2024, Hermann Vosseler <Ichthyostega@web.de>
|
|
|
|
|
|
|
|
|
|
|
|
**Lumiera** is free software; you can redistribute it and/or modify it
|
|
|
|
|
|
under the terms of the GNU General Public License as published by the
|
|
|
|
|
|
Free Software Foundation; either version 2 of the License, or (at your
|
|
|
|
|
|
option) any later version. See the file COPYING for further details.
|
|
|
|
|
|
|
|
|
|
|
|
* *****************************************************************/
|
|
|
|
|
|
|
|
|
|
|
|
/** @file del-stash-test.cpp
|
|
|
|
|
|
** unit test \ref HeteroData_test
|
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#include "lib/test/run.hpp"
|
|
|
|
|
|
#include "lib/hetero-data.hpp"
|
2024-12-10 19:40:45 +01:00
|
|
|
|
#include "lib/meta/trait.hpp"
|
|
|
|
|
|
#include "lib/test/diagnostic-output.hpp"/////////////////TODO
|
2024-12-11 02:36:17 +01:00
|
|
|
|
#include "lib/util.hpp"
|
Invocation: develop a concept for handling parameter data
...as part of the rendering process, executed on top of the
low-level-model (Render Node network) as conceived thus far.
Parameter handling could be ''encoded'' into render nodes altogether,
or, at the other extreme, an explicit parameter handling could be specified
as part of the Render Node execution. As both extremes will lead to some
unfavourable consequences, I am aiming at a middle ground: largely, the
''automation computation'' will be encoded and hidden within the network,
implying that this topic remains to be addressed as part of defining
the Builder semantics and implementation. Yet in part the required
processing structure can be foreseen at an abstract level, and thus
the essential primitive operations are specified explicitly as part
of the Render Node definition. Notably the ''standard Weaving Pattern''
will include a ''parameter tuple'' into each `FeedManifold` and require
a binding function, which accepts this tuple as first argument.
Moreover — at implementation level, a library facility must be provided
to support handling of ''arbitrary heterogeneous data values'' embedded
directly into stack frame memory, together with a type-safe compile-time
overlay, which allows the builder to embed specific ''accessor handles''
into functor bindings, even while the actual storage location is not
yet known at that time (obviously, as being located on the stack).
__Note__: a recurring topic is how to return descriptor objects from builder functions; for this purpose, I am adjusting the semantics of `lib/nocopy.hpp` to be more specific...
2024-12-09 21:55:48 +01:00
|
|
|
|
|
2024-12-11 02:36:17 +01:00
|
|
|
|
#include <string>
|
Invocation: develop a concept for handling parameter data
...as part of the rendering process, executed on top of the
low-level-model (Render Node network) as conceived thus far.
Parameter handling could be ''encoded'' into render nodes altogether,
or, at the other extreme, an explicit parameter handling could be specified
as part of the Render Node execution. As both extremes will lead to some
unfavourable consequences, I am aiming at a middle ground: largely, the
''automation computation'' will be encoded and hidden within the network,
implying that this topic remains to be addressed as part of defining
the Builder semantics and implementation. Yet in part the required
processing structure can be foreseen at an abstract level, and thus
the essential primitive operations are specified explicitly as part
of the Render Node definition. Notably the ''standard Weaving Pattern''
will include a ''parameter tuple'' into each `FeedManifold` and require
a binding function, which accepts this tuple as first argument.
Moreover — at implementation level, a library facility must be provided
to support handling of ''arbitrary heterogeneous data values'' embedded
directly into stack frame memory, together with a type-safe compile-time
overlay, which allows the builder to embed specific ''accessor handles''
into functor bindings, even while the actual storage location is not
yet known at that time (obviously, as being located on the stack).
__Note__: a recurring topic is how to return descriptor objects from builder functions; for this purpose, I am adjusting the semantics of `lib/nocopy.hpp` to be more specific...
2024-12-09 21:55:48 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
namespace lib {
|
|
|
|
|
|
namespace test{
|
|
|
|
|
|
|
2024-12-11 02:36:17 +01:00
|
|
|
|
using std::string;
|
2024-12-10 19:40:45 +01:00
|
|
|
|
using meta::is_Subclass;
|
2024-12-11 02:36:17 +01:00
|
|
|
|
using util::isSameObject;
|
2024-12-10 19:40:45 +01:00
|
|
|
|
|
2024-12-10 23:23:41 +01:00
|
|
|
|
|
Invocation: develop a concept for handling parameter data
...as part of the rendering process, executed on top of the
low-level-model (Render Node network) as conceived thus far.
Parameter handling could be ''encoded'' into render nodes altogether,
or, at the other extreme, an explicit parameter handling could be specified
as part of the Render Node execution. As both extremes will lead to some
unfavourable consequences, I am aiming at a middle ground: largely, the
''automation computation'' will be encoded and hidden within the network,
implying that this topic remains to be addressed as part of defining
the Builder semantics and implementation. Yet in part the required
processing structure can be foreseen at an abstract level, and thus
the essential primitive operations are specified explicitly as part
of the Render Node definition. Notably the ''standard Weaving Pattern''
will include a ''parameter tuple'' into each `FeedManifold` and require
a binding function, which accepts this tuple as first argument.
Moreover — at implementation level, a library facility must be provided
to support handling of ''arbitrary heterogeneous data values'' embedded
directly into stack frame memory, together with a type-safe compile-time
overlay, which allows the builder to embed specific ''accessor handles''
into functor bindings, even while the actual storage location is not
yet known at that time (obviously, as being located on the stack).
__Note__: a recurring topic is how to return descriptor objects from builder functions; for this purpose, I am adjusting the semantics of `lib/nocopy.hpp` to be more specific...
2024-12-09 21:55:48 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*************************************************************//**
|
|
|
|
|
|
* @test maintain a sequence of data tuples in local storage,
|
|
|
|
|
|
* providing pre-configured type-safe data access.
|
|
|
|
|
|
*
|
|
|
|
|
|
* @see lib::HeteroData
|
|
|
|
|
|
* @see NodeBase_test::verify_TurnoutSystem()
|
|
|
|
|
|
*/
|
|
|
|
|
|
class HeteroData_test : public Test
|
|
|
|
|
|
{
|
|
|
|
|
|
|
|
|
|
|
|
virtual void
|
|
|
|
|
|
run (Arg)
|
|
|
|
|
|
{
|
|
|
|
|
|
// seedRand();
|
|
|
|
|
|
// checksum = 0;
|
|
|
|
|
|
|
2024-12-10 23:23:41 +01:00
|
|
|
|
verify_FrontBlock();
|
2024-12-11 02:36:17 +01:00
|
|
|
|
verify_ChainBlock();
|
Invocation: develop a concept for handling parameter data
...as part of the rendering process, executed on top of the
low-level-model (Render Node network) as conceived thus far.
Parameter handling could be ''encoded'' into render nodes altogether,
or, at the other extreme, an explicit parameter handling could be specified
as part of the Render Node execution. As both extremes will lead to some
unfavourable consequences, I am aiming at a middle ground: largely, the
''automation computation'' will be encoded and hidden within the network,
implying that this topic remains to be addressed as part of defining
the Builder semantics and implementation. Yet in part the required
processing structure can be foreseen at an abstract level, and thus
the essential primitive operations are specified explicitly as part
of the Render Node definition. Notably the ''standard Weaving Pattern''
will include a ''parameter tuple'' into each `FeedManifold` and require
a binding function, which accepts this tuple as first argument.
Moreover — at implementation level, a library facility must be provided
to support handling of ''arbitrary heterogeneous data values'' embedded
directly into stack frame memory, together with a type-safe compile-time
overlay, which allows the builder to embed specific ''accessor handles''
into functor bindings, even while the actual storage location is not
yet known at that time (obviously, as being located on the stack).
__Note__: a recurring topic is how to return descriptor objects from builder functions; for this purpose, I am adjusting the semantics of `lib/nocopy.hpp` to be more specific...
2024-12-09 21:55:48 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-12-11 02:36:17 +01:00
|
|
|
|
/** @test build a free standing data tuple block to start a chain */
|
Invocation: develop a concept for handling parameter data
...as part of the rendering process, executed on top of the
low-level-model (Render Node network) as conceived thus far.
Parameter handling could be ''encoded'' into render nodes altogether,
or, at the other extreme, an explicit parameter handling could be specified
as part of the Render Node execution. As both extremes will lead to some
unfavourable consequences, I am aiming at a middle ground: largely, the
''automation computation'' will be encoded and hidden within the network,
implying that this topic remains to be addressed as part of defining
the Builder semantics and implementation. Yet in part the required
processing structure can be foreseen at an abstract level, and thus
the essential primitive operations are specified explicitly as part
of the Render Node definition. Notably the ''standard Weaving Pattern''
will include a ''parameter tuple'' into each `FeedManifold` and require
a binding function, which accepts this tuple as first argument.
Moreover — at implementation level, a library facility must be provided
to support handling of ''arbitrary heterogeneous data values'' embedded
directly into stack frame memory, together with a type-safe compile-time
overlay, which allows the builder to embed specific ''accessor handles''
into functor bindings, even while the actual storage location is not
yet known at that time (obviously, as being located on the stack).
__Note__: a recurring topic is how to return descriptor objects from builder functions; for this purpose, I am adjusting the semantics of `lib/nocopy.hpp` to be more specific...
2024-12-09 21:55:48 +01:00
|
|
|
|
void
|
2024-12-11 02:36:17 +01:00
|
|
|
|
verify_FrontBlock()
|
Invocation: develop a concept for handling parameter data
...as part of the rendering process, executed on top of the
low-level-model (Render Node network) as conceived thus far.
Parameter handling could be ''encoded'' into render nodes altogether,
or, at the other extreme, an explicit parameter handling could be specified
as part of the Render Node execution. As both extremes will lead to some
unfavourable consequences, I am aiming at a middle ground: largely, the
''automation computation'' will be encoded and hidden within the network,
implying that this topic remains to be addressed as part of defining
the Builder semantics and implementation. Yet in part the required
processing structure can be foreseen at an abstract level, and thus
the essential primitive operations are specified explicitly as part
of the Render Node definition. Notably the ''standard Weaving Pattern''
will include a ''parameter tuple'' into each `FeedManifold` and require
a binding function, which accepts this tuple as first argument.
Moreover — at implementation level, a library facility must be provided
to support handling of ''arbitrary heterogeneous data values'' embedded
directly into stack frame memory, together with a type-safe compile-time
overlay, which allows the builder to embed specific ''accessor handles''
into functor bindings, even while the actual storage location is not
yet known at that time (obviously, as being located on the stack).
__Note__: a recurring topic is how to return descriptor objects from builder functions; for this purpose, I am adjusting the semantics of `lib/nocopy.hpp` to be more specific...
2024-12-09 21:55:48 +01:00
|
|
|
|
{
|
2024-12-10 19:40:45 +01:00
|
|
|
|
using Block1 = HeteroData<uint,double>;
|
2024-12-10 23:23:41 +01:00
|
|
|
|
CHECK ((is_Subclass<Block1::NewFrame, std::tuple<uint,double>>()));
|
Invocation: develop a concept for handling parameter data
...as part of the rendering process, executed on top of the
low-level-model (Render Node network) as conceived thus far.
Parameter handling could be ''encoded'' into render nodes altogether,
or, at the other extreme, an explicit parameter handling could be specified
as part of the Render Node execution. As both extremes will lead to some
unfavourable consequences, I am aiming at a middle ground: largely, the
''automation computation'' will be encoded and hidden within the network,
implying that this topic remains to be addressed as part of defining
the Builder semantics and implementation. Yet in part the required
processing structure can be foreseen at an abstract level, and thus
the essential primitive operations are specified explicitly as part
of the Render Node definition. Notably the ''standard Weaving Pattern''
will include a ''parameter tuple'' into each `FeedManifold` and require
a binding function, which accepts this tuple as first argument.
Moreover — at implementation level, a library facility must be provided
to support handling of ''arbitrary heterogeneous data values'' embedded
directly into stack frame memory, together with a type-safe compile-time
overlay, which allows the builder to embed specific ''accessor handles''
into functor bindings, even while the actual storage location is not
yet known at that time (obviously, as being located on the stack).
__Note__: a recurring topic is how to return descriptor objects from builder functions; for this purpose, I am adjusting the semantics of `lib/nocopy.hpp` to be more specific...
2024-12-09 21:55:48 +01:00
|
|
|
|
|
2024-12-10 19:40:45 +01:00
|
|
|
|
auto b1 = Block1::build (42, 1.61803);
|
2024-12-10 23:23:41 +01:00
|
|
|
|
CHECK (1.61803 == b1.get<1>());
|
|
|
|
|
|
CHECK (42 == b1.get<0>());
|
|
|
|
|
|
CHECK (showType<Block1::Elm_t<0>>() == "uint"_expect);
|
|
|
|
|
|
CHECK (showType<Block1::Elm_t<1>>() == "double"_expect);
|
|
|
|
|
|
|
|
|
|
|
|
Block1 b2;
|
|
|
|
|
|
CHECK (0.0 == b2.get<1>());
|
|
|
|
|
|
b2.get<1>() = 3.14;
|
|
|
|
|
|
CHECK (3.14 == b2.get<1>());
|
2024-12-11 21:01:25 +01:00
|
|
|
|
|
|
|
|
|
|
CHECK (2 == std::tuple_size_v<Block1::NewFrame::Tuple>); // referring to the embedded tuple type
|
|
|
|
|
|
CHECK (2 == std::tuple_size_v<Block1::NewFrame>); // StorageFrame itself complies to the C++ tuple protocol
|
|
|
|
|
|
CHECK (2 == std::tuple_size_v<Block1>); // likewise for the complete HeteroData Chain
|
Invocation: develop a concept for handling parameter data
...as part of the rendering process, executed on top of the
low-level-model (Render Node network) as conceived thus far.
Parameter handling could be ''encoded'' into render nodes altogether,
or, at the other extreme, an explicit parameter handling could be specified
as part of the Render Node execution. As both extremes will lead to some
unfavourable consequences, I am aiming at a middle ground: largely, the
''automation computation'' will be encoded and hidden within the network,
implying that this topic remains to be addressed as part of defining
the Builder semantics and implementation. Yet in part the required
processing structure can be foreseen at an abstract level, and thus
the essential primitive operations are specified explicitly as part
of the Render Node definition. Notably the ''standard Weaving Pattern''
will include a ''parameter tuple'' into each `FeedManifold` and require
a binding function, which accepts this tuple as first argument.
Moreover — at implementation level, a library facility must be provided
to support handling of ''arbitrary heterogeneous data values'' embedded
directly into stack frame memory, together with a type-safe compile-time
overlay, which allows the builder to embed specific ''accessor handles''
into functor bindings, even while the actual storage location is not
yet known at that time (obviously, as being located on the stack).
__Note__: a recurring topic is how to return descriptor objects from builder functions; for this purpose, I am adjusting the semantics of `lib/nocopy.hpp` to be more specific...
2024-12-09 21:55:48 +01:00
|
|
|
|
}
|
2024-12-11 02:36:17 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/** @test construct a follow-up data tuple block and hook it into the chain */
|
|
|
|
|
|
void
|
|
|
|
|
|
verify_ChainBlock()
|
|
|
|
|
|
{
|
|
|
|
|
|
using Block1 = HeteroData<uint>;
|
|
|
|
|
|
CHECK ((is_Subclass<Block1::NewFrame, std::tuple<uint>>()));
|
|
|
|
|
|
|
|
|
|
|
|
using Constructor = Block1::Chain<double,string>;
|
|
|
|
|
|
using Block2 = Constructor::NewFrame;
|
|
|
|
|
|
CHECK ((is_Subclass<Block2, std::tuple<double, string>>()));
|
|
|
|
|
|
|
|
|
|
|
|
auto b1 = Block1::build (41);
|
|
|
|
|
|
auto b2 = Constructor::build (1.61, "Φ");
|
|
|
|
|
|
b2.linkInto(b1);
|
|
|
|
|
|
|
2024-12-11 21:01:25 +01:00
|
|
|
|
using Chain2 = Constructor::ChainType;
|
|
|
|
|
|
Chain2& chain2 = reinterpret_cast<Chain2&> (b1);
|
2024-12-11 02:36:17 +01:00
|
|
|
|
CHECK (b1.size() == 1);
|
|
|
|
|
|
CHECK (chain2.size() == 3);
|
|
|
|
|
|
|
|
|
|
|
|
CHECK (41 == chain2.get<0>());
|
|
|
|
|
|
CHECK (1.61 == chain2.get<1>());
|
|
|
|
|
|
CHECK ("Φ" == chain2.get<2>());
|
|
|
|
|
|
|
|
|
|
|
|
chain2.get<0>()++;
|
|
|
|
|
|
chain2.get<1>() = (1 + sqrt(5)) / 2;
|
|
|
|
|
|
|
|
|
|
|
|
CHECK (b1.get<0>() == 42);
|
|
|
|
|
|
CHECK (chain2.get<0>() == 42);
|
|
|
|
|
|
CHECK (std::get<0> (b2) == "1.618034"_expect);
|
|
|
|
|
|
|
|
|
|
|
|
CHECK (isSameObject (chain2.get<0>() ,b1.get<0>()));
|
|
|
|
|
|
CHECK (isSameObject (chain2.get<2>() ,std::get<1>(b2)));
|
2024-12-11 21:01:25 +01:00
|
|
|
|
|
|
|
|
|
|
CHECK (1 == std::tuple_size_v<Block1::NewFrame::Tuple>); // referring to the embedded tuple type
|
|
|
|
|
|
CHECK (1 == std::tuple_size_v<Block1::NewFrame>);
|
|
|
|
|
|
CHECK (1 == std::tuple_size_v<Block1>);
|
|
|
|
|
|
|
|
|
|
|
|
CHECK (2 == std::tuple_size_v<Block2::Tuple>); // referring to the embedded tuple type
|
|
|
|
|
|
CHECK (2 == std::tuple_size_v<Block2>);
|
|
|
|
|
|
|
|
|
|
|
|
CHECK (3 == std::tuple_size_v<Chain2>);
|
|
|
|
|
|
CHECK ((showType<std::tuple_element_t<0, Chain2>>() == "uint"_expect));
|
|
|
|
|
|
CHECK ((showType<std::tuple_element_t<1, Chain2>>() == "double"_expect));
|
|
|
|
|
|
CHECK ((showType<std::tuple_element_t<2, Chain2>>() == "string"_expect));
|
|
|
|
|
|
|
|
|
|
|
|
CHECK ((showType<std::tuple_element_t<0, Block2>>() == "double"_expect));
|
|
|
|
|
|
CHECK ((showType<std::tuple_element_t<1, Block2>>() == "string"_expect));
|
|
|
|
|
|
|
|
|
|
|
|
CHECK (std::get<0> (chain2) == 42);
|
|
|
|
|
|
// CHECK (std::get<1> (chain2) == "1.618034"_expect); ////////////////////////////TODO somehow the overload for std::tuple takes precedence here
|
|
|
|
|
|
// CHECK (std::get<2> (chain2) == "Φ"_expect);
|
|
|
|
|
|
|
|
|
|
|
|
CHECK (std::get<0> (b2) == "1.618034"_expect);
|
|
|
|
|
|
CHECK (std::get<1> (b2) == "Φ"_expect);
|
2024-12-11 02:36:17 +01:00
|
|
|
|
}
|
Invocation: develop a concept for handling parameter data
...as part of the rendering process, executed on top of the
low-level-model (Render Node network) as conceived thus far.
Parameter handling could be ''encoded'' into render nodes altogether,
or, at the other extreme, an explicit parameter handling could be specified
as part of the Render Node execution. As both extremes will lead to some
unfavourable consequences, I am aiming at a middle ground: largely, the
''automation computation'' will be encoded and hidden within the network,
implying that this topic remains to be addressed as part of defining
the Builder semantics and implementation. Yet in part the required
processing structure can be foreseen at an abstract level, and thus
the essential primitive operations are specified explicitly as part
of the Render Node definition. Notably the ''standard Weaving Pattern''
will include a ''parameter tuple'' into each `FeedManifold` and require
a binding function, which accepts this tuple as first argument.
Moreover — at implementation level, a library facility must be provided
to support handling of ''arbitrary heterogeneous data values'' embedded
directly into stack frame memory, together with a type-safe compile-time
overlay, which allows the builder to embed specific ''accessor handles''
into functor bindings, even while the actual storage location is not
yet known at that time (obviously, as being located on the stack).
__Note__: a recurring topic is how to return descriptor objects from builder functions; for this purpose, I am adjusting the semantics of `lib/nocopy.hpp` to be more specific...
2024-12-09 21:55:48 +01:00
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/** Register this test class... */
|
|
|
|
|
|
LAUNCHER (HeteroData_test, "unit common");
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
}} // namespace lib::test
|