Address of a class object

[H. S. Teoh]

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.