2015-04-02 03:30:20 +02:00
|
|
|
|
/*
|
2016-02-26 22:57:49 +01:00
|
|
|
|
TreeMutator(Test) - customisable intermediary to abstract tree changing operations
|
2015-04-02 03:30:20 +02:00
|
|
|
|
|
Copyright: clarify and simplify the file headers
* Lumiera source code always was copyrighted by individual contributors
* there is no entity "Lumiera.org" which holds any copyrights
* Lumiera source code is provided under the GPL Version 2+
== Explanations ==
Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above.
For this to become legally effective, the ''File COPYING in the root directory is sufficient.''
The licensing header in each file is not strictly necessary, yet considered good practice;
attaching a licence notice increases the likeliness that this information is retained
in case someone extracts individual code files. However, it is not by the presence of some
text, that legally binding licensing terms become effective; rather the fact matters that a
given piece of code was provably copyrighted and published under a license. Even reformatting
the code, renaming some variables or deleting parts of the code will not alter this legal
situation, but rather creates a derivative work, which is likewise covered by the GPL!
The most relevant information in the file header is the notice regarding the
time of the first individual copyright claim. By virtue of this initial copyright,
the first author is entitled to choose the terms of licensing. All further
modifications are permitted and covered by the License. The specific wording
or format of the copyright header is not legally relevant, as long as the
intention to publish under the GPL remains clear. The extended wording was
based on a recommendation by the FSF. It can be shortened, because the full terms
of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
|
|
|
|
Copyright (C)
|
|
|
|
|
|
2015, Hermann Vosseler <Ichthyostega@web.de>
|
2015-04-02 03:30:20 +02:00
|
|
|
|
|
Copyright: clarify and simplify the file headers
* Lumiera source code always was copyrighted by individual contributors
* there is no entity "Lumiera.org" which holds any copyrights
* Lumiera source code is provided under the GPL Version 2+
== Explanations ==
Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above.
For this to become legally effective, the ''File COPYING in the root directory is sufficient.''
The licensing header in each file is not strictly necessary, yet considered good practice;
attaching a licence notice increases the likeliness that this information is retained
in case someone extracts individual code files. However, it is not by the presence of some
text, that legally binding licensing terms become effective; rather the fact matters that a
given piece of code was provably copyrighted and published under a license. Even reformatting
the code, renaming some variables or deleting parts of the code will not alter this legal
situation, but rather creates a derivative work, which is likewise covered by the GPL!
The most relevant information in the file header is the notice regarding the
time of the first individual copyright claim. By virtue of this initial copyright,
the first author is entitled to choose the terms of licensing. All further
modifications are permitted and covered by the License. The specific wording
or format of the copyright header is not legally relevant, as long as the
intention to publish under the GPL remains clear. The extended wording was
based on a recommendation by the FSF. It can be shortened, because the full terms
of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
|
|
|
|
**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.
|
2015-04-02 03:30:20 +02:00
|
|
|
|
|
Copyright: clarify and simplify the file headers
* Lumiera source code always was copyrighted by individual contributors
* there is no entity "Lumiera.org" which holds any copyrights
* Lumiera source code is provided under the GPL Version 2+
== Explanations ==
Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above.
For this to become legally effective, the ''File COPYING in the root directory is sufficient.''
The licensing header in each file is not strictly necessary, yet considered good practice;
attaching a licence notice increases the likeliness that this information is retained
in case someone extracts individual code files. However, it is not by the presence of some
text, that legally binding licensing terms become effective; rather the fact matters that a
given piece of code was provably copyrighted and published under a license. Even reformatting
the code, renaming some variables or deleting parts of the code will not alter this legal
situation, but rather creates a derivative work, which is likewise covered by the GPL!
The most relevant information in the file header is the notice regarding the
time of the first individual copyright claim. By virtue of this initial copyright,
the first author is entitled to choose the terms of licensing. All further
modifications are permitted and covered by the License. The specific wording
or format of the copyright header is not legally relevant, as long as the
intention to publish under the GPL remains clear. The extended wording was
based on a recommendation by the FSF. It can be shortened, because the full terms
of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
|
|
|
|
* *****************************************************************/
|
2015-04-02 03:30:20 +02:00
|
|
|
|
|
2017-02-22 01:54:20 +01:00
|
|
|
|
/** @file tree-mutator-test.cpp
|
2017-02-22 03:17:18 +01:00
|
|
|
|
** unit test \ref TreeMutator_test
|
2016-11-03 18:20:10 +01:00
|
|
|
|
*/
|
|
|
|
|
|
|
2015-04-02 03:30:20 +02:00
|
|
|
|
|
|
|
|
|
|
#include "lib/test/run.hpp"
|
2015-08-28 23:09:10 +02:00
|
|
|
|
#include "lib/format-util.hpp"
|
2015-04-02 03:30:20 +02:00
|
|
|
|
#include "lib/test/test-helper.hpp"
|
|
|
|
|
|
#include "lib/diff/tree-mutator.hpp"
|
2016-01-07 03:58:29 +01:00
|
|
|
|
#include "lib/format-cout.hpp"
|
2016-08-29 23:04:44 +02:00
|
|
|
|
#include "lib/format-util.hpp"
|
2015-04-02 03:30:20 +02:00
|
|
|
|
#include "lib/util.hpp"
|
|
|
|
|
|
|
|
|
|
|
|
#include <string>
|
2016-08-29 23:04:44 +02:00
|
|
|
|
#include <vector>
|
2015-04-02 03:30:20 +02:00
|
|
|
|
|
|
|
|
|
|
using util::isnil;
|
2016-08-29 23:04:44 +02:00
|
|
|
|
using util::join;
|
2016-01-08 08:20:59 +01:00
|
|
|
|
using util::typeStr;
|
settle on a concrete implementation approach based on inheritance chain
After some reconsideration, I decide to stick to the approach with the closures,
but to use a metaprotramming technique to build an inheritance chain.
While I can not decide on the real world impact of storing all those closures,
in theory this approach should enable the compiler to remove all of the
storage overhead. Since, when storing the result into an auto variable
right within scope (as demonstrated in the test), the compiler
sees the concrete type and might be able to boil down the actual
generated virtual function implementations, thereby inlining the
given closures.
Whereas, on the other hand, if we'd go the obvious conventional route
and place the closures into a Map allocated on the stack, I wouldn't
expect the compiler to do data flow analysis to prove this allocation
is not necessary and inline it away.
NOTE: there is now guarantee this inlining trick will ever work.
And, moreover, we don't know anything regarding the runtime effect.
The whole picture is way more involved as it might seem at first sight.
Even if we go the completely conventional route and require every
participating object to supply an implementation of some kind of
"Serializable" interface, we'll end up with a (hand written!)
implementation class for each participating setup, which takes
up space in the code segment of the executable. While the closure
based approach chosen here, consumes data segment (or heap) space
per instance for the functors (or function pointers) representing
the closures, plus code segment space for the closures, but the
latter with a way higher potential for inlining, since the closure
code and the generated virtual functions are necessarily emitted
within the same compilation unit and within a local (inline, not
publickly exposed) scope.
2015-04-05 18:26:49 +02:00
|
|
|
|
|
2016-08-29 23:04:44 +02:00
|
|
|
|
using std::string;
|
|
|
|
|
|
using std::vector;
|
|
|
|
|
|
|
2015-04-02 03:30:20 +02:00
|
|
|
|
|
|
|
|
|
|
namespace lib {
|
|
|
|
|
|
namespace diff{
|
|
|
|
|
|
namespace test{
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*****************************************************************************//**
|
|
|
|
|
|
* @test Demonstrate a customisable component for flexible bindings
|
|
|
|
|
|
* to enable generic tree changing and mutating operations to
|
|
|
|
|
|
* arbitrary hierarchical data structures.
|
2016-08-29 23:04:44 +02:00
|
|
|
|
* - we use lambdas to link into our private implementation
|
|
|
|
|
|
* - this test demonstrates the behaviour of an attribute setter
|
|
|
|
|
|
* - plus some of the _primitive operations_ available on collections
|
2015-04-02 03:30:20 +02:00
|
|
|
|
*
|
|
|
|
|
|
* @see TreeMutator
|
2016-08-29 23:04:44 +02:00
|
|
|
|
* @see DiffComplexApplication_test a way more complex usage scenario
|
2019-12-12 23:41:26 +01:00
|
|
|
|
* @see GenNode_test
|
|
|
|
|
|
* @see GenericRecord_test
|
2015-04-02 03:30:20 +02:00
|
|
|
|
*/
|
2016-02-26 22:57:49 +01:00
|
|
|
|
class TreeMutator_test : public Test
|
2015-04-02 03:30:20 +02:00
|
|
|
|
{
|
|
|
|
|
|
|
|
|
|
|
|
virtual void
|
|
|
|
|
|
run (Arg)
|
|
|
|
|
|
{
|
|
|
|
|
|
simpleAttributeBinding();
|
2016-08-29 23:04:44 +02:00
|
|
|
|
simpleCollectionBinding();
|
2015-04-02 03:30:20 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
|
simpleAttributeBinding()
|
|
|
|
|
|
{
|
2016-08-29 23:04:44 +02:00
|
|
|
|
MARK_TEST_FUN;
|
2015-04-02 03:30:20 +02:00
|
|
|
|
string localData;
|
settle on a concrete implementation approach based on inheritance chain
After some reconsideration, I decide to stick to the approach with the closures,
but to use a metaprotramming technique to build an inheritance chain.
While I can not decide on the real world impact of storing all those closures,
in theory this approach should enable the compiler to remove all of the
storage overhead. Since, when storing the result into an auto variable
right within scope (as demonstrated in the test), the compiler
sees the concrete type and might be able to boil down the actual
generated virtual function implementations, thereby inlining the
given closures.
Whereas, on the other hand, if we'd go the obvious conventional route
and place the closures into a Map allocated on the stack, I wouldn't
expect the compiler to do data flow analysis to prove this allocation
is not necessary and inline it away.
NOTE: there is now guarantee this inlining trick will ever work.
And, moreover, we don't know anything regarding the runtime effect.
The whole picture is way more involved as it might seem at first sight.
Even if we go the completely conventional route and require every
participating object to supply an implementation of some kind of
"Serializable" interface, we'll end up with a (hand written!)
implementation class for each participating setup, which takes
up space in the code segment of the executable. While the closure
based approach chosen here, consumes data segment (or heap) space
per instance for the functors (or function pointers) representing
the closures, plus code segment space for the closures, but the
latter with a way higher potential for inlining, since the closure
code and the generated virtual functions are necessarily emitted
within the same compilation unit and within a local (inline, not
publickly exposed) scope.
2015-04-05 18:26:49 +02:00
|
|
|
|
auto mutator =
|
|
|
|
|
|
TreeMutator::build()
|
2015-05-03 05:24:06 +02:00
|
|
|
|
.change("data", [&](string val)
|
settle on a concrete implementation approach based on inheritance chain
After some reconsideration, I decide to stick to the approach with the closures,
but to use a metaprotramming technique to build an inheritance chain.
While I can not decide on the real world impact of storing all those closures,
in theory this approach should enable the compiler to remove all of the
storage overhead. Since, when storing the result into an auto variable
right within scope (as demonstrated in the test), the compiler
sees the concrete type and might be able to boil down the actual
generated virtual function implementations, thereby inlining the
given closures.
Whereas, on the other hand, if we'd go the obvious conventional route
and place the closures into a Map allocated on the stack, I wouldn't
expect the compiler to do data flow analysis to prove this allocation
is not necessary and inline it away.
NOTE: there is now guarantee this inlining trick will ever work.
And, moreover, we don't know anything regarding the runtime effect.
The whole picture is way more involved as it might seem at first sight.
Even if we go the completely conventional route and require every
participating object to supply an implementation of some kind of
"Serializable" interface, we'll end up with a (hand written!)
implementation class for each participating setup, which takes
up space in the code segment of the executable. While the closure
based approach chosen here, consumes data segment (or heap) space
per instance for the functors (or function pointers) representing
the closures, plus code segment space for the closures, but the
latter with a way higher potential for inlining, since the closure
code and the generated virtual functions are necessarily emitted
within the same compilation unit and within a local (inline, not
publickly exposed) scope.
2015-04-05 18:26:49 +02:00
|
|
|
|
{
|
2015-05-02 01:39:58 +02:00
|
|
|
|
cout << "\"data\" closure received something "<<val<<endl;
|
settle on a concrete implementation approach based on inheritance chain
After some reconsideration, I decide to stick to the approach with the closures,
but to use a metaprotramming technique to build an inheritance chain.
While I can not decide on the real world impact of storing all those closures,
in theory this approach should enable the compiler to remove all of the
storage overhead. Since, when storing the result into an auto variable
right within scope (as demonstrated in the test), the compiler
sees the concrete type and might be able to boil down the actual
generated virtual function implementations, thereby inlining the
given closures.
Whereas, on the other hand, if we'd go the obvious conventional route
and place the closures into a Map allocated on the stack, I wouldn't
expect the compiler to do data flow analysis to prove this allocation
is not necessary and inline it away.
NOTE: there is now guarantee this inlining trick will ever work.
And, moreover, we don't know anything regarding the runtime effect.
The whole picture is way more involved as it might seem at first sight.
Even if we go the completely conventional route and require every
participating object to supply an implementation of some kind of
"Serializable" interface, we'll end up with a (hand written!)
implementation class for each participating setup, which takes
up space in the code segment of the executable. While the closure
based approach chosen here, consumes data segment (or heap) space
per instance for the functors (or function pointers) representing
the closures, plus code segment space for the closures, but the
latter with a way higher potential for inlining, since the closure
code and the generated virtual functions are necessarily emitted
within the same compilation unit and within a local (inline, not
publickly exposed) scope.
2015-04-05 18:26:49 +02:00
|
|
|
|
localData = val;
|
|
|
|
|
|
});
|
2015-04-02 03:30:20 +02:00
|
|
|
|
|
2015-05-02 01:39:58 +02:00
|
|
|
|
cout << "concrete TreeMutator size=" << sizeof(mutator)
|
2016-01-08 08:20:59 +01:00
|
|
|
|
<< " type="<< typeStr(mutator)
|
2015-05-02 01:39:58 +02:00
|
|
|
|
<< endl;
|
2015-04-02 03:30:20 +02:00
|
|
|
|
|
2016-10-04 03:24:44 +02:00
|
|
|
|
mutator.init();
|
|
|
|
|
|
|
2015-04-02 03:30:20 +02:00
|
|
|
|
CHECK (isnil (localData));
|
2016-05-28 03:41:03 +02:00
|
|
|
|
string testValue{"that would be acceptable"};
|
|
|
|
|
|
mutator.assignElm ({"lore", testValue});
|
2015-05-02 01:39:58 +02:00
|
|
|
|
CHECK ( isnil (localData)); // nothing happens, nothing changed
|
2016-05-28 03:41:03 +02:00
|
|
|
|
mutator.assignElm ({"data", testValue});
|
settle on a concrete implementation approach based on inheritance chain
After some reconsideration, I decide to stick to the approach with the closures,
but to use a metaprotramming technique to build an inheritance chain.
While I can not decide on the real world impact of storing all those closures,
in theory this approach should enable the compiler to remove all of the
storage overhead. Since, when storing the result into an auto variable
right within scope (as demonstrated in the test), the compiler
sees the concrete type and might be able to boil down the actual
generated virtual function implementations, thereby inlining the
given closures.
Whereas, on the other hand, if we'd go the obvious conventional route
and place the closures into a Map allocated on the stack, I wouldn't
expect the compiler to do data flow analysis to prove this allocation
is not necessary and inline it away.
NOTE: there is now guarantee this inlining trick will ever work.
And, moreover, we don't know anything regarding the runtime effect.
The whole picture is way more involved as it might seem at first sight.
Even if we go the completely conventional route and require every
participating object to supply an implementation of some kind of
"Serializable" interface, we'll end up with a (hand written!)
implementation class for each participating setup, which takes
up space in the code segment of the executable. While the closure
based approach chosen here, consumes data segment (or heap) space
per instance for the functors (or function pointers) representing
the closures, plus code segment space for the closures, but the
latter with a way higher potential for inlining, since the closure
code and the generated virtual functions are necessarily emitted
within the same compilation unit and within a local (inline, not
publickly exposed) scope.
2015-04-05 18:26:49 +02:00
|
|
|
|
CHECK (!isnil (localData));
|
2015-05-02 01:39:58 +02:00
|
|
|
|
cout << "localData changed to: "<<localData<<endl;
|
|
|
|
|
|
CHECK (localData == "that would be acceptable");
|
2015-04-02 03:30:20 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void
|
2016-08-29 23:04:44 +02:00
|
|
|
|
simpleCollectionBinding()
|
2015-04-02 03:30:20 +02:00
|
|
|
|
{
|
2016-08-29 23:04:44 +02:00
|
|
|
|
MARK_TEST_FUN;
|
|
|
|
|
|
vector<string> values;
|
|
|
|
|
|
values.push_back("a");
|
|
|
|
|
|
values.push_back("b");
|
|
|
|
|
|
|
|
|
|
|
|
cout << join(values) <<endl;
|
|
|
|
|
|
CHECK (2 == values.size());
|
|
|
|
|
|
CHECK ("a, b" == join(values));
|
|
|
|
|
|
|
|
|
|
|
|
auto mutator =
|
|
|
|
|
|
TreeMutator::build()
|
|
|
|
|
|
.attach (collection(values));
|
|
|
|
|
|
|
|
|
|
|
|
cout << "concrete TreeMutator size=" << sizeof(mutator)
|
|
|
|
|
|
<< " type="<< typeStr(mutator)
|
|
|
|
|
|
<< endl;
|
|
|
|
|
|
|
2016-10-04 03:24:44 +02:00
|
|
|
|
mutator.init();
|
|
|
|
|
|
|
2016-08-29 23:04:44 +02:00
|
|
|
|
CHECK (isnil (values));
|
|
|
|
|
|
CHECK (mutator.matchSrc (GenNode("a")));
|
|
|
|
|
|
mutator.skipSrc (GenNode("a"));
|
|
|
|
|
|
CHECK (mutator.matchSrc (GenNode("b")));
|
|
|
|
|
|
CHECK (mutator.injectNew (GenNode("c")));
|
|
|
|
|
|
CHECK (mutator.acceptSrc (GenNode("b")));
|
|
|
|
|
|
|
|
|
|
|
|
cout << join(values) <<endl;
|
|
|
|
|
|
CHECK (2 == values.size());
|
|
|
|
|
|
CHECK ("c, b" == join(values));
|
2015-04-02 03:30:20 +02:00
|
|
|
|
}
|
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/** Register this test class... */
|
2016-02-26 22:57:49 +01:00
|
|
|
|
LAUNCHER (TreeMutator_test, "unit common");
|
2015-04-02 03:30:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
}}} // namespace lib::diff::test
|