Click here to Skip to main content
11,795,848 members (79,686 online)
Rate this: bad
Please Sign up or sign in to vote.
See more: C++ size delete memory
Hello folks,

i would be heavily interested, to know where a standard/normal "operator new"-function implementation does store the size of the variable. I know from the C++ specification, that the operator new expression expands to a call of the operator new function, of the appropriate class. This call passes the size_t of the memory to allocate.

But where does the function store the size? I mean, the delete and the sizeof operator must get this size from somewhere?!
My first idea was, it would be stored in-front of the data (BSTR like), but i have never seen anything else than the data itself in the memory view window.
For example, if i create an int with value 3, there is only the "0x03" itself at the memory, no size before or behind...


Posted 8-Jul-12 21:28pm
Rate this: bad
Please Sign up or sign in to vote.

Solution 1

Rate this: bad
Please Sign up or sign in to vote.

Solution 2

Operator new inside usually calls the API function HeapAlloc. Operator delete calls HeapFree. As you can see, this is all WinAPI inside. Now all you need is to use heap api.
Memory is allocated by blocks, much like a linked list. All you need is to walk these blocks. Try using HeapWalk.
Rate this: bad
Please Sign up or sign in to vote.

Solution 3

There are numerous implementations of the new operator from one compiler to the next, plus there are many ways to allocate different types of memory, such as local or global, or in stack or in the heap.

Read about memory management on the platform where your question applies, and about the exact methods of memory allocation that you use.

Beside that, I can only tell you where memory pointer is allocated physically on the x86 platform, regardless of some high-level operators, if you are curious Wink | ;) And it goes like this...(no, u think u're ready?) Smile | :)

First of all, selector register points at either GDT[^] or LDT[^], depending on its bit 2 status. Then the address register points at either memory itself, in case of flat memory model, or page index + offset, in case of the virtual mode. The bottom line, memory is physically allocated in pages these days, and the swap flag is supported by the x86 processors, so it can trigger an interrupt wherever a task is trying to access a page marked as swapped and the handler loads it up. Yep, that old chestnut. And this is how it works in Windows too Wink | ;)

Do you still want to know where your memory size is stored? Smile | :) Smile | :) Smile | :) Memory size within a process is always virtual, not real, and it can be stored anywhere, as long as the supporting API knows how to deal with it. Welcome to the virtual age, my friend Wink | ;)

P.S. It's not the size, mate, it's how you use it Smile | :) Smile | :) Smile | :)
Rate this: bad
Please Sign up or sign in to vote.

Solution 4

That is totally dependent on the allocator that is used by the default implementation of the global new/delete operators. The default global/new delete operators are totally dependent on your compiler (on its standard library to be accurate). You can even override the default global new/delete operators and provide your own implementation and then you are free to work with your free memory and to optimize the speed of allocation/deallocation. You don't even have to store the size near to the chunk if your allocator library is able to tell the size for a pointer.
Overriding the global new/delete operators is a common technique to introduce some advanced debugging, and to collect statistics about the most commonly allocated chunk sizes to introduce a faster allocator (usually a linked array) just for the those sizes. (This helps avoiding fragmentation too!)

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
0 Maciej Los 410
1 Abhinav S 368
2 OriginalGriff 300
3 Sergey Alexandrovich Kryukov 266
4 KrunalRohit 249
0 OriginalGriff 1,852
1 Maciej Los 1,465
2 KrunalRohit 1,300
3 CPallini 840
4 Richard MacCutchan 828

Advertise | Privacy | Mobile
Web04 | 2.8.151002.1 | Last Updated 9 Jul 2012
Copyright © CodeProject, 1999-2015
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100