how to get virtual pointer?

[everid]

Hi guys,
Is there a way to access the virtual pointer which points to the virtual table?
Another question is that, how to remember the size of "new"?
say:
int* ip=new int[30];
is there a way to remember this size of 30? without introducing an extra variable say: int size=30.
I think it is possible but i just don't know how to. because we can do
delete [] ip;
without mentioning the size at all.
thanks.

[firedraco]

Nope, I don't believe so.

I think it is because the computer knows exactly where your memory is, and how much is allocated to the pointer, but the pointer itself doesn't know. You'll have to store it in a variable (or #define if it is a constant type value).

[writetonsharma]

virtual pointer or the rtti information is generally stored in the first four bytes of the class object. so you can experiment with it to take out that information.

if you do this:

int* ip=new int[30];
ip += 5;

delete [] ip; // it will crash, this shows that new keeps the number of bytes allocated to any pointer. now in this case it will bypass the boundary.

[jsmith]

The way it works is malloc stores the length of the allocated buffer in the few bytes immediately before the pointer it returns.

For example, if you malloc( 20 ), malloc will actually allocate more than 20 bytes. If it reserves the memory from address 0x1000 to 0x1020, it would, for example, put the length of the buffer (32) at addresses 0x1000-0x1003 and return 0x1004 to the caller.

Multiple inheritance is more complicated. Why would you want to get the vtable pointer anyway?

[everid]

Hi Guys, I try to do this for curiosity. Because as i learn c++, i find that there are too many things hidden. without knowing them, i just don't feel confidence. I'm always feeling like using a black box when programming in c++.
How about you guys?

[Disch]

I don't think the way malloc or new work internally is something you should bother with or rely upon, as it is totally implementation dependent, and expecting it to be a certain way when it compiles another way could result in dire consequences. You're better off remembering the size of an allocated buffer elsewhere (like in a seperate 'size' variable as per the original post)

i find that there are too many things hidden

The nature of a HLL is that many things will be hidden. It's kind of the point. If you want to have control over every minor thing, you can always try out assembly, but even then you'll probably have to resort to standard libs for stuff, which means you're still at the mercy of "black box" library implementation.

The reason details of this kind of thing is hidden is because the details may vary from platform to platform, or even from compiler to compiler. The general rule I try to follow is that you can rely on established behavior, but assume that anything outside of what is explicitly set can be anything and isn't something you need to concern yourself with (and you're better off not dealing with it anyway).

So as far as you should be concerned -- malloc and new do not provide a way to get the size of the allocated buffer. Even though they may track that information internally -- since the way in which that is done (if at all) isn't standardized, you can't/shouldn't take advantage of it in your program.

[writetonsharma]

hehehe.. you are right.. but things come with experience.. as you and me today learned that four bytes before the array are reserved for the length of the buffer allocated.
i knew new/malloc store the length somewhere but didnt know where!!!

jsmith:

what you said seems to be correct but the actual length stored is somewhat weird..
lets say i did this:

char *ptr = (char*)malloc(3);
printf("%d",*(ptr - 4)); //this gives 17 every time till a malloc of 12bytes

char *ptr = (char*)malloc(13);
printf("%d",*(ptr - 4)); //this gives 25 every time

char *ptr = (char*)malloc(40);
printf("%d",*(ptr - 4)); //this gives 49 every time 

the counts looks to be increasing in steps, and doesnt seem to be correct!!! any idea??

secondly, if somehow we figure out how the count is generating then will this give any segmentation fault:

char *ptr = (char*)malloc(16); //this will allocate 16 + 4 bytes, correct or whatever?
//*(ptr - 4) == 20
*(ptr + 0) = 16; //free will think that next 12 bytes are two be freed only..
ptr += 4; //i am the owner of next 12 bytes only
free(ptr); //what you say?? 

[writetonsharma]

for your information:

uname -or
2.6.18-8.el5xen GNU/Linux

gcc --version
gcc (GCC) 4.3.3

[jsmith]

It is because malloc has a minimum allocation unit of 16 bytes and it likely grows by 8 bytes, no matter what size you request. Also, because malloc() always allocates blocks that are multiples of 4 bytes, the lowest 2 bits in the "length" can be used for other purposes.

Your second example, assuming you make the previous 4 bytes look "correct" probably could work, though at the expense of a leak of a couple of bytes of memory that is now neither allocated nor on the free list.

As Disch pointed out, however, this is all compiler dependent, and my knowledge is based on gcc. (I'm guessing malloc has not changed in a long long time on gcc).

[Disch]

I suspect debug builds in MSVS might allocate more space than you request and fill it with marker values (like 0xCDCDCDCD or something), then check that space upon free() and give you an error if it changed (simple way to catch stepping out of bounds).

This kind of thing might be runtime lib dependent too. I don't know whether or not malloc is part of a distributed runtime lib -- but if it is, different machines might have malloc act differently. So even if you compile a program and it works fine on your machine, that same exe might break if someone else runs it on their machine.

[writetonsharma]

hmmm.. you people are right.. it was just a spontaneous question only.. im not going to do anything of this sort in my lifetime.. hehehe... :D

[everid]

I learned a lot but is more confused than before. After all, whatever, i learned a lot. Thank you guys.