• monkyyy (53/53) Sep 12 2020 I intend to write 6 reasonably-general high-quality data
• monkyyy (37/37) Sep 12 2020 So, what I'm worried about is making member indexed arrays in

monkyyy <crazymonkyyy gmail.com> writes:

I intend to write 6 reasonably-general high-quality data 
structures that's complies with the standards of the std to 
submit it to the std.

Data structure summery(details on the github):
---

1. Ring array: an array with an access pattern that loops back on 
itself rather then overflowing
2. Opinionated list of lists: A array of nullable!T, where null 
is an end of a list.
3. Metadata: like nullable, but adds additional 7 bit int to 
round out the wasted space of nullable, and more flexible in 
usage pattern.
4. Member index arrays: A lighter version of SoA. Given a user 
defined T and a member of T, packs the designated members 
together for better cache usage for searches.
5. Fixed length string: When you want char[n] rather then the 
default char[].
6. Semi-static array: no gc, copy to larger array during overflow 
and custom allocator friendly array abstraction.

-----------

Month 1
----

* Get a dub package up and running.
* Get ring arrays to "feature complete".
* Make a *bodged* a-b fuzzy race testing/benchmarking framework 
that generates markdown test results.
   * Bodged: makeshift, slipshod, not intended to be stable.
* Make prototypes for the other 5 data structures.
* Learn d style and inline documentation system the community 
likes, adding it to ring array

Month 2
---

* Make/find a more robust testing system.
   * testing correctness of specific cases, as opposed to a fuzzer 
and benchmarker.
* Publish a-b test *results* on github inviting the community to 
criticize it in issues.
* Improve 3 more data structures to "feature complete".
   * The flexibility of which data structures is intended. To pace 
myself, or for interdependence, for example I will use metadata 
in opinionated list of list.

Month 3
---

* Improve remaining data structures to "feature complete".
* "Finalize" ring array.
* Respond to community feedback.

Month 4
---

* "Finalize" remaining data structures.
* Submit code to the std review process.

----

https://github.com/crazymonkyyy/datastuctureplayground
I primarily am in the discord.

monkyyy <crazymonkyyy gmail.com> writes:

So, what I'm worried about is making member indexed arrays in 
such a way that is standards complaint.

I have written a (semi-) functional aosoa, but my abstractions 
there where very much mine, and heavy template abuse *to the 
point it only worked on one compiler*.


```
struct cow{
   vec2 pos;
   vec2 vel;
   int milk;
   void update(){
     pos+=vel;
     milk++;
}}
memberindexedarray!(cow,pos) cows;
cows[0..100].map!update;
```

Making that work while deconstruction the cow into pieces is 
possible the abstraction I used in aosoa was "pointy" or roughly
```
struct pointy!cow{
   vec2* pos;
   partialcow* partialcow_;
   ... etc
}
```

with allot of really jank code that I was told repeatably was 
ugly.

While this is simpler then what I had, its still the same sort of 
problem and I expect to be playing with the edges of the 
compilers definition where the bugs are.

context:
https://www.youtube.com/watch?v=YGTZr6bmNmk - a lecture of what 
aosoa is, *in human*
https://www.dataorienteddesign.com/dodbook/node7.html#SECTION
0720000000000000000 - the chapter of the "dod book" of the idea for this came
form
https://github.com/crazymonkyyy/monkeydata - my aosoa lib
https://github.com/crazymonkyyy/datastuctureplayground/blob/master/planning/definetely%20d
ing/indexedarray.md -my current thoughts on member indexed arrays