On Wed, Jan 04, 2023 at 01:20:12PM -0800, Ali Çehreli via Digitalmars-d-learn wrote: > On 1/4/23 12:02, Steven Schveighoffer wrote: > > On 1/4/23 2:27 PM, Ali Çehreli wrote: > > >> I put the objects into a 2-length > >> static array but the difference was still 0x20. (?) > > > > Are you putting the class *references* in a 2-length static array? > > I lied. As I could not put the objects in a static array, I put them > on the stack with the 'scope' keyword and the difference was still > 0x20. (Of course, I could emplace the objects myself in my static > array but that wouldn't prove anything about why the current alignment > appears to be 0x20.)
You do realize that the compiler is free to reorder local variables on the stack, right? ;-) Generally it doesn't, but nothing in the spec precludes it from doing so. Highly-optimizing compilers like ldc also tend to move code around, and with it, any associated local variables, so exactly where something is put on the stack isn't really something you can rely on. And of course, stuff on the stack may also be subject to alignment requirements depending on your CPU/architecture. Though generally speaking this shouldn't be any stricter than alignment requirements on general heap/GC allocations. > > stop worrying about the addresses given out by the GC > > No worries; just trying to explain... [...] I think at this point any explanation is likely to involve many more implementation-specific details than is warranted for understanding D code. :-P It can of course be extremely interesting (and instructive) to know about these details, but one has to keep in mind that the deeper one digs, the more non-portable these implementation details become, and the more divergences you'll see across different CPUs and OSes. T -- Insanity is doing the same thing over and over again and expecting different results.