Wird erwartet, dass der neue zusätzliche Platz auf dem Haufen zuteilt? [Duplikat] ⇐ C++

[Anonymous]

Ich habe ein kleines Problem geschrieben, um ein Beispiel für die Stapel- und Haufen -Zuordnung anzuzeigen, und ich bin durch das Verhalten verwirrt. < /p>

Code: Select all

int main()
{
unsigned int s1,s2,s3;
printf("Stack memory addresses: s1=0x%x\ts2=0x%x\ts3=0x%x\n", &s1, &s2, &s3);

int *h1, *h2, *h3;
h1 = new int;
h2 = new int;
h3 = new int;
printf("Heap memory addresses: h1=0x%x\th2=0x%x\th3=0x%x\n", h1, h2, h3);
}
< /code>
Die Ausgabe lautet: < /p>
Stack memory addresses: s1=0xb90aa73c   s2=0xb90aa738   s3=0xb90aa734
Heap memory addresses: h1=0x24c4030 h2=0x24c4050    h3=0x24c4060
< /code>
Was ich auf dem Stapel sehe, ist genau das, was ich erwartet hatte, aber ich bin verwirrt über den Haufen.  Es scheint 32 Bytes für die erste Ganzzahl und 16 für die zweite zuzuweisen.  Ich habe erneut mit Optimierungen zusammengestellt, um '-O0' ausgeschaltet zu sein und ich verstehe das. < /P>
Stack memory addresses: s1=0xbde7b73c   s2=0xbde7b738   s3=0xbde7b734
Heap memory addresses: h1=0x1318000 h2=0x1318010    h3=0x1318020
< /code>
Mit Optimierungen sind manchmal nur 16 Bytes pro Ganzzahl zugewiesen, aber es ist nicht konsistent.  Manchmal verhält es sich ohne Optimierungen gleich.  Die zweite Frage, unabhängig davon, warum dieses Gedächtnis zugewiesen ist, warum ist es inkonsistent.    .section    __TEXT,__text,regular,pure_instructions
.build_version macos, 15, 0 sdk_version 15, 2
.globl  _main                           ## -- Begin function main
.p2align    4, 0x90
_main:                                  ## @main
.cfi_startproc
## %bb.0:
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset %rbp, -16
movq    %rsp, %rbp
.cfi_def_cfa_register %rbp
subq    $48, %rsp
leaq    L_.str(%rip), %rdi
leaq    -4(%rbp), %rsi
leaq    -8(%rbp), %rdx
leaq    -12(%rbp), %rcx
movb    $0, %al
callq   _printf
movl    $4, %edi
callq   __Znwm
movq    %rax, -24(%rbp)
movl    $4, %edi
callq   __Znwm
movq    %rax, -32(%rbp)
movl    $4, %edi
callq   __Znwm
movq    %rax, -40(%rbp)
movq    -24(%rbp), %rsi
movq    -32(%rbp), %rdx
movq    -40(%rbp), %rcx
leaq    L_.str.1(%rip), %rdi
movb    $0, %al
callq   _printf
xorl    %eax, %eax
addq    $48, %rsp
popq    %rbp
retq
.cfi_endproc
## -- End function
.section    __TEXT,__cstring,cstring_literals
L_.str:                                 ## @.str
.asciz  "Stack memory addresses: s1=0x%x\ts2=0x%x\ts3=0x%x\n"

L_.str.1:                               ## @.str.1
.asciz  "Heap memory addresses: h1=0x%x\th2=0x%x\th3=0x%x\n"

.subsections_via_symbols
< /code>
Ich gebe nicht vor, ASM wirklich zu verstehen, aber aus meinem begrenzten Verständnis gab es drei Aufrufe, 4 Bytes zuzuweisen.  Jeweils gefolgt von einer 8 -Byte -Speicheradresse, die an den Basizeiger übergeben wird.  Wenn ich hier mit:
g ++ test_o0.s -o test_o0 < /p>
kompilieren kann, erhalte ich erneut entweder 16 oder 32 Bytes zwischen Werten.  Es scheint, dass der neue Anruf dies tut.  Warum passiert das? < /P>
Stack memory addresses: s1=0xb573a72c   s2=0xb573a728   s3=0xb573a724
Heap memory addresses: h1=0xa68030  h2=0xa68050 h3=0xa68060