c++ memory management
Author
I came along this very interesting site : site and now I am wondering where I can find resources describing memory management in C++ ? What are the different available alternatives?
I am sure there is more than just calling new and delete.
new and delete must be used very carefully, otherwise memory leakage will ensue. But yes, there is more beyond new and delete... there is malloc() (and related functions). They are used to explicitly allocate memory for data. One just has to remember to free() the memory to avoid memory leaks. I'm pretty sure there are other things, but they are beyond me.
Memory management is a pretty broad subject.
Direct3D has a memory management system which you interact with via AddRef() and Release(). You can use smart pointers to manage pointers that point to dynamically allocated memory such that it is not leaked. You can overload new and delete in order to manually manage the location and organisation of memory allocations.
Which of these options has you interested?
Direct3D has a memory management system which you interact with via AddRef() and Release(). You can use smart pointers to manage pointers that point to dynamically allocated memory such that it is not leaked. You can overload new and delete in order to manually manage the location and organisation of memory allocations.
Which of these options has you interested?
Author
I was more referring to what happens inside new and delete. Apparently there are different strategies there, if I use the terms of www.memorymanagement.org you have :
First Fit, Buddy System. I am sure there are others. So how does this translate in C++ ? does this relates the different allocators one can give to STL containers ?
First Fit, Buddy System. I am sure there are others. So how does this translate in C++ ? does this relates the different allocators one can give to STL containers ?
Quote:
I am sure there are others. So how does this translate in C++ ?
Unspecified. The C++ standard does not mandate the method used to lookup/allocate/manage/release memory acquired via new and freed with delete. Most implementations will likely fall through to the underlying OS allocation routines, which may use whatever allocation scheme makes sense.
Quote:
does this relates the different allocators one can give to STL containers ?
The allocators are used to customize how memory is allocated for SC++L containers, but not what new and delete actually end up doing. So they're somewhat related, but not really...
Author
From what I understand the OS in terms of memory management doesn't deal with things smaller than a page : something around 4Kb or more.
So I was wandering how these pages where managed by the C++ allocator/deallocator, and what options/strategies were available.
So I was wandering how these pages where managed by the C++ allocator/deallocator, and what options/strategies were available.
Well, that depends on the OS. Even if they use that kind of granularity internally, most will expose some method of carving up blocks into smaller chunks or something; most OSs probably have more memory management functionality that you realize. After all, recall that all of the C++ standard library features (and all features of other languages, too) are ultimately implemented on top of the functionality provided by the OS. On modern non-embedded systems, at least.
That said, all of this stuff varies widely -- as I said before, there are few restrictions placed upon an implementation by the C++ specification. You can use Google to search for memory management information (resources on OS theory are a useful source). You can also consult the documentation for the core APIs for your OS (such as the Platform SDK documentation on MSDN). To get an idea of what you might want to look for there, write up a simple C++ program that performs a dynamic allocation and use your debugger to step into it. Follow it far enough, just like fopen() and the like, you will arrive at an OS function eventually and possibly gain some insight into what implementation your development environment is employing.
That said, all of this stuff varies widely -- as I said before, there are few restrictions placed upon an implementation by the C++ specification. You can use Google to search for memory management information (resources on OS theory are a useful source). You can also consult the documentation for the core APIs for your OS (such as the Platform SDK documentation on MSDN). To get an idea of what you might want to look for there, write up a simple C++ program that performs a dynamic allocation and use your debugger to step into it. Follow it far enough, just like fopen() and the like, you will arrive at an OS function eventually and possibly gain some insight into what implementation your development environment is employing.
Well if you want to take a look to alternative allocation strategy there's boost::pool. In the library documentation it's described pool principles and simple segregate storage. Instead if you want to see how a professional C++ compiler manage memory allocation take a look at gcc source code.
Quote:Original post by jpetrieQuote:
does this relates the different allocators one can give to STL containers ?
The allocators are used to customize how memory is allocated for SC++L containers, but not what new and delete actually end up doing. So they're somewhat related, but not really...
Do note that STL (SC++L looks overly convoluted :\ ) allocators are not guaranteed to be used by "list" and associative containers since they are node based. This is because STL allocators only allocate T type objects not the ListNode<T> or MapNode<T> objects that node based containers need.
Quote:Original post by T1OracleQuote:Original post by jpetrieQuote:
does this relates the different allocators one can give to STL containers ?
The allocators are used to customize how memory is allocated for SC++L containers, but not what new and delete actually end up doing. So they're somewhat related, but not really...
Do note that STL (SC++L looks overly convoluted :\ ) allocators are not guaranteed to be used by "list" and associative containers since they are node based. This is because STL allocators only allocate T type objects not the ListNode<T> or MapNode<T> objects that node based containers need.
Wrong. SC++L allocators must expose Allocator::rebind<U>::other, also an allocator, which allows an allocator to be adapted to a new type U, where U can be, say, a node type.
[Edited by - MaulingMonkey on June 16, 2007 9:26:09 AM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement