My software is a "piggyback operating system". It took me 26 years to craft. It is written mostly in C++ with a tiny amount of inline assembler macros and assembler modules. It is a general purpose programming environment for the C++ language.
I wrote the whole thing the way that I thought it should be designed, with no consideration for conventional practice and no concern for whether it would be too weird to be accepted. One example is that for the database subsystem, I did it the way that I felt was most natural within the context of the C++ language. Although it can mimic the semantics of a relational database, it has a simpler and more general and more powerful and more efficient architecture.
The basic architectural building block is the "list". A list can be of anything, including other lists. Here is the console output that I've been debugging all day today.
Scroll to the right to read the important part of the listing. The "application" list contains one record. That record contains one field. That field contains a single integer, with the value of 1.
000b3e37.0ff746b9 ! 00000000.00000000 @ 00000000.00000000 # 1 $ 1 % tm1F | NUMA: this process will default to limiting itself to using a single NUMA node on NUMA computers [idNumaNode]: 2
000b3e37.0ff8c12e ! 00000000.00017a75 @ 00000000.000000f8 # 1 $ 1 % tm1F | chattering application
000b3e37.0ff8c160 ! 00000000.00017aa7 @ 00000000.00000032 # 1 $ 1 % tm1F | adam.temp.20021015.cdf3 | ------------------------------------------------------------------------------- ROOT/ROOTaPPLICATION
000b3e37.0ff8c227 ! 00000000.00017b6e @ 00000000.000000c7 # 1 $ 1 % tm1F | adam.temp.20021015.cdf3 | 0 | p: 80d02dd | a: 565ed1 | LIST my.record
000b3e37.0ff8c28a ! 00000000.00017bd1 @ 00000000.00000063 # 1 $ 1 % tm1F | adam.temp.20021015.cdf3 | ------------------------------------------------------------------------------- ROOT/ROOTaPPLICATION/"my.record"
000b3e37.0ff8c31f ! 00000000.00017c66 @ 00000000.00000095 # 1 $ 1 % tm1F | adam.temp.20021015.cdf3 | 1 | p: 4ec02dd | a: 561ed1 | LIST my.field
000b3e37.0ff8c383 ! 00000000.00017cca @ 00000000.00000064 # 1 $ 1 % tm1F | adam.temp.20021015.cdf3 | ------------------------------------------------------------------------------- ROOT/ROOTaPPLICATION/"my.record"/"my.field"
000b3e37.0ff8c47b ! 00000000.00017dc2 @ 00000000.000000f8 # 1 $ 1 % tm1F | adam.temp.20021015.cdf3 | 2 | p: c2639f01 | a: 4890e3 | listing countT: 1
000b3e37.0ff8c47b ! 00000000.00017dc2 @ 00000000.00000000 # 1 $ 1 % tm1F | chattered application
000b3e37.0ff8c47b ! 00000000.00017dc2 @ 00000000.00000000 # 1 $ 1 % tm1F | ok
The "list subsystem" is both contained within, and used by, the heap subsystem. IOW, the data is kept in the heap, which makes it blazingly fast. What makes this a database system is that in my software, you can have multiple heaps, and some of them can persist. (This is all done with memory mapping.)
The code has been in production for about 15 years but used only within the heap system to have nested heaps (which reduces the address space footprint). Now that I'm beginning to work on reporting web site traffic, my initial code revealed bugs in the list subsystem. So I have a few weeks (at least) of testing and development to do on the list subsystem before I can resume working on the traffic reporting project.