Example of how Datum works with generic_data_handle.
#2466
Conversation
This commit adds an example (by means of unit-tests) that demonstrates the behaviour we see #2458. It involves understanding how raw pointers and pointers to values inside a `soa` are function. It further demonstrates the difference of `generic_data_handle::get` and `generic_data_handle::literal_value`.
1uc
force-pushed
the
1uc/example-pointer
branch
from
d9ea8f9
to
eaef32c
Compare
This comment has been minimized.
This comment has been minimized.
|
✔️ eaef32c -> Azure artifacts URL |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #2466 +/- ##
==========================================
+ Coverage 60.41% 60.43% +0.02%
==========================================
Files 626 627 +1
Lines 120812 120849 +37
==========================================
+ Hits 72990 73039 +49
+ Misses 47822 47810 -12 ☔ View full report in Codecov by Sentry. |
This comment has been minimized.
This comment has been minimized.
|
✔️ 3df0376 -> Azure artifacts URL |
|
✔️ 4f37e6e -> Azure artifacts URL |
This comment has been minimized.
This comment has been minimized.
1uc
force-pushed
the
1uc/example-pointer
branch
from
4f37e6e
to
01a198e
Compare
| // We set up everything such that the `soa` containers have two voltages. | ||
| // We'll now study what happens to a Datum that refers to one of these. In | ||
| // generated code this datum is called `_ppval[0]`. The | ||
| Datum* _ppval = (Datum*) malloc(sizeof(Datum)); |
There was a problem hiding this comment.
| Datum* _ppval = (Datum*) malloc(sizeof(Datum)); | |
| auto* const _ppval = new Datum{}; |
is the minimum change needed here, so that the constructor is called. Otherwise this is treating uninitialised memory as a Datum object.
I don't see why it needs to be on the heap, though.
There was a problem hiding this comment.
It can be an std::vector. It doesn't need to be dynamically allocated. The point is to keep the similarity to the generated code. The name is _ppval[0]. Hence we need some things that gives us an operator[].
There was a problem hiding this comment.
Perhaps we should move
TEST_CASE("generic_data_handle", "[Neuron][data_structures][generic_data_handle]") {
from node.cpp into here.
|
This is just code to check that my understanding of the issue faced in #2458. I'm not sure we want to merge it at all. |
|
✔️ 01a198e -> Azure artifacts URL |
1uc
force-pushed
the
1uc/example-pointer
branch
from
01a198e
to
d18ddae
Compare
|
✔️ d18ddae -> Azure artifacts URL |
|
@1uc : for merge, this should be rebased on master? |
|
I'm not sure we'd want to merge this. These tests aren't new. Some of them are dumb and demonstrate an obvious point (to the point of being confusing without the context). The reason for this code is: In #2458 we were trying to figure out how these two macros would behave: Since I was doing a lot of guessing, I needed to write code to check my understanding of the data structures. In order to share these examples, written in the form of tests because a) that's convenient way to get something to compile; and b) useful to assert various statements, I created this PR. The conclusion is that neither is quite right:
Additionally,
|
|
Ok, I will let you / @nrnhines / @iomaganaris to decide on the usefulness. (Even if they are are not tests but useful examples for a new person, wondering if they should go somewhere.) |
This commit adds an example (by means of unit-tests) that demonstrates the behaviour we see #2458. It involves understanding how raw pointers and pointers to values inside a
soaare function. It further demonstrates the difference ofgeneric_data_handle::getandgeneric_data_handle::literal_value.