vector<A*> vec;
for(int x=0; x < 10; x++){
B ob;
vec.push_back(&ob);
}
vec[5]->getv();
Scope question
Author
This code shouldnt work correctly, right? The objects stored at the adress are destroyed when the loop is over so why does this still function as normal?
b is derived class of A.
Perhaps the memory at that location hasnt yet been overwritten allowing you to still use the objects.
I wouldn't be surprised if the compiler was waiting until the end of the routine to free the memory, either that or what Invader X said.
Author
I did a test by storing addresses of classes in a vector, by storing the x value inside of them ( from 0 to 9 ). After the loop exited every vector had the last x value stored in it, which was 9.
Well, what compiler are you using? You could probably look at the assembly generated by the compiler to see what it's doing; actually, I guess I can test it right now.
Author
Dev-cpp IDE, mingw32-c++ compiler, how do I do that? I cant even get the debugger on this working, it doesnt do anything.
Well, you'd have to know assembly. Here's a test program I compiled:
It's in C, but it shouldn't matter. Anyway, this is what gcc produced for the assembly output:
This was compiled on a 64-bit machine, and my assembly skills aren't what they used to be, but from what I can make out it looks like gcc, and by extension mingw, allocate and deallocate stack space on-demand for blocks, meaning Invader X is probably right.
#include <stdio.h>int main() { for(int i=0; i<10; ++i) { int c = i; printf("%d\n", c); } return 0;}It's in C, but it shouldn't matter. Anyway, this is what gcc produced for the assembly output:
.file "test.c" .section .rodata.LC0: .string "%d\n" .text.globl main .type main, @functionmain:.LFB3: pushq %rbp.LCFI0: movq %rsp, %rbp.LCFI1: subq $16, %rsp.LCFI2: movl $0, -4(%rbp).L2: cmpl $9, -4(%rbp) jle .L5 jmp .L3.L5: movl -4(%rbp), %eax movl %eax, -8(%rbp) movl -8(%rbp), %esi movl $.LC0, %edi movb $0, %al call printf leaq -4(%rbp), %rax incl (%rax) jmp .L2.L3: movl $0, %eax leave ret.LFE3: .size main, .-main .section .eh_frame,"a",@progbits.Lframe1: .long .LECIE1-.LSCIE1.LSCIE1: .long 0x0 .byte 0x1 .string "" .uleb128 0x1 .sleb128 -8 .byte 0x10 .byte 0xc .uleb128 0x7 .uleb128 0x8 .byte 0x90 .uleb128 0x1 .align 8.LECIE1:.LSFDE1: .long .LEFDE1-.LASFDE1.LASFDE1: .long .LASFDE1-.Lframe1 .quad .LFB3 .quad .LFE3-.LFB3 .byte 0x4 .long .LCFI0-.LFB3 .byte 0xe .uleb128 0x10 .byte 0x86 .uleb128 0x2 .byte 0x4 .long .LCFI1-.LCFI0 .byte 0xd .uleb128 0x6 .align 8.LEFDE1: .section .note.GNU-stack,"",@progbits .ident "GCC: (GNU) 3.3.5 (Debian 1:3.3.5-8ubuntu2)"This was compiled on a 64-bit machine, and my assembly skills aren't what they used to be, but from what I can make out it looks like gcc, and by extension mingw, allocate and deallocate stack space on-demand for blocks, meaning Invader X is probably right.
Author
i know assembly, but this debugger doesnt even do anything, im used to DOS Debug, not this Dev-CPP Debug that has no effect.
The reason it works is that the vector does a copy of the object. You probably don't implement a copy cstr or operator= so it does a memberwise copy creating a new copy of your objects.
Cheers
Chris
Cheers
Chris
Quote:Original post by chollida1
The reason it works is that the vector does a copy of the object. You probably don't implement a copy cstr or operator= so it does a memberwise copy creating a new copy of your objects.
Cheers
Chris
He's pushing the address of the objects, not the actual objects themselves.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement