On Tue, Feb 24, 2026 at 04:21:01PM +0000, monkyyy via Digitalmars-d-learn wrote: > On Tuesday, 24 February 2026 at 16:19:05 UTC, H. S. Teoh wrote: > > On Tue, Feb 24, 2026 at 03:56:20PM +0000, monkyyy via > > Digitalmars-d-learn wrote: > > > On Tuesday, 24 February 2026 at 15:30:39 UTC, H. S. Teoh wrote: [...] > > > > > What's a "fat struct"? > > [...] > > > Something like a "entity" that has a first member is a id allowing > > > for intrusive sumtypes from void* pointers or a giant union and > > > just allot of data. > > [...] > > > > So is that like ECS or something along those lines? [...] > Related ideas, but ecs will definitely have components which is a > whole thing of complexity and makes for scheduling and you start > talking about custom compilers. > > All good ecs will probably be fat structs, but components are not > necessarily members of good entities.
Hmm. So basically the idea is to stuff everything into a single struct so that you keep everything in cache instead of having to dereference pointers? Sounds like something you could use compile-time introspection for. Say you have some kind of compile-time spec of what sub-structs go into some entity, then have compile-time code auto-generate the fat struct that contains everything in these sub-structs. Could do it in a way that makes it easy to change at the code level without editing tons of struct definitions (by using CTFE to generate said definitions and then mix them in). T -- "If this is the solution, I want my precipitate back."
