   Memory Allocation: OS vs Software Level
  Long story short.  Is OS allocation up to par these days or is it better to manage your own memory?  'new' compared to 'class.Request()'My guess would be on managing your own, but I've come to grow tired of toying with large arrays of data.  So, if that's the case, could someone point me in the right direction of proper Cpp self memory management?  Last thing I want to do is create some C spawn in a Cpp environment; which is exactly what I would do.  Though, if C is the answer, I'm more than willing to break a few Cpp syntax rules.Much appreciated.   
  Maybe you should write out the long story, because what you wrote here doesn't make any sense to me...   ;  There really is no story to be honest, it's more a matter of me trying to be lazy.  Consider if you will some class object, in which you will need to create and destroy continuously throughout the run of your game.  You could use 'new' and 'delete' in Cpp, or create your own memory management and garbage collection.class Manager{//A lack of variables.  I'm lazy.public:int* Request();void Release();};My most condensed and simplistic question would be:  How far can I get away with using 'new' and 'delete' without it being a burden on my program?  Might it be sufficient enough for a small time game such as...  Frogger?   ;  If you think `new' and `delete' are implemented by the OS, you probably are not ready to write your own allocator. I am sure the standard `new' provided by your C++ compiler will serve you well for years.;  Use new/delete. Please don't use some other mechanism in C++ code.Even if you want to do something fancy, like pool the allocations, new/delete are operators that your classes can overload.e.g. in my engine I've got some objects that only live for a single frame, so I have an overloaded new/delete in a class called TemporaryObject which optimises these single-frame allocations. I can then write:class TempWidget : public TemporaryObject{//Widget code};TempWidget* pWidget = new TempWidget;//^^This actually allocates the memory by calling TemporaryObject::Allocate!//Do some stuff...delete pWidget;//^^This actually frees the memory by calling TemporaryObject::Free!So yeah, in a big project you might not want to use the built-in new/delete for everything (though it's fine for most things), you can still use the new/delete syntax all the time (by overloading those operators to do "clever stuff" when you really need to).Quote:Original post by GreedfulMy most condensed and simplistic question would be:  How far can I get away with using 'new' and 'delete' without it being a burden on my program?  Might it be sufficient enough for a small time game such as...  Frogger?I've seen new/delete used extensively in the game-play code of 360/PS3 games, so you won't be stuck at Frogger ;)Quote:or create your own memory management and garbage collection.If don't want to have to manage the lifetimes of your objects yourself (i.e. figure out when to delete), a lot of people will recommend boost's shared_ptr.   ;  I recommend you the Scalable Allocator, included into the Intel Thread Building Blocks library:http://www.threadingbuildingblocks.orgThe malloc implementation that comes by default in most compilers is far to be efficient, gives poor performance, and even in some compilers that OS function isn't  thread-safe at all(gnu-gcc libc, clang).But the Scalable Allocator allows you to frequently create and destroy objects without any significant performance loss. Also this allocator allows you to take advantage of parallel processing in multi-core systems.For using that allocator in your classes you have to overwrite the new operator, like this:inline void* operator new(size_t sizeInBytes){    return scalable_malloc(sizeInBytes); }inline void  operator delete(void* ptr){   scalable_free(ptr); }inline void* operator new(size_t, void* ptr){   return ptr;}inline void  operator delete(void*, void*){}I'm not sure why do you want a Garbage Collector, because that is an exclusive feature for fancy scripting languages (Just for solving circular references). With a simple mechanism for counting references and smart pointers is just enough for managing your objects memory safely.   ;  Wow, thanks for the great replies everyone.Quote:I've seen new/delete used extensively in the game-play code of 360/PS3 games, so you won't be stuck at FroggerWonderful post if I might say Hodgman, but can you clear up the whole overriding aspect of new and delete? class::Allocate, and class::Free right?  As for the console aspect of things.  I'm sure Microsoft and Sony have really tidied up their memory allocation.  You'll get maximum performance with any console whereas an operating system has a much broader picture to focus on.Quote:The malloc implementation that comes by default in most compilers is far to be efficient, gives poor performance, and even in some compilers that OS function isn't thread-safe at all(gnu-gcc libc, clang).Exactly the answer I was looking for!  Thanks a bunch superoptimo, I'll go check out that Scalable Allocator right now.  In the meantime, I'd be interested in also learning more about memory management at the bottom level.  Might you have any suggestions?P.S.  The garbage collector thing was just to let others know what I was getting at.  Though, if GCs are used for specific things only, does that mean most programs merely request more memory rather than organizing it?  I can only assume it's much better to ask for large sections of memory compared to 4 bytes at a time.;  Just to clear something up to the op. The OS is the guardian of the machine, as such memory and all other resources are allocated and control by the OS. So whether it new/malloc or Win32 Heap functions, all the call still go through the OS. Its just a matter if you want a higher level call vs something that 'lower level'.   ;  There is also a huge difference between general purpose memory allocation by the OS, who organizes memory in some hierarchical structure (e.g. red-black-trees), so that there are not too many inaccessable holes of memory, and custom memory allocation where you know beforehand what you need for which purpose. Surely, handcoded memory pools and other specializations are much faster if done correctly, but a general purpose memory manager (with unknown limits and nearly no assumptions on what is to be allocated) which beats the OS' own ones is extremely hard to write. And, in that sense, without writing custom low-level modules to be plugged onto the kernel, you can't skip away the OS' allocator anyways.Your OS, whichever that is, is the result of hundreds of man-years of reasearch. Not infallible, but hard to beat even for gurus.edit: But if you are really talking about C++ memory management (new delete malloc free), before writing your own, maybe look at the suggested threading-building-blocks, or hoard or maybe nedmalloc. Or, as you also seem to confuse C++ memory management with the OS' memory management, don't do it at all, now, and not for the next few years.   ;  a) I completely agree with Phresnelb) If you want your own memory management, overload new & delete operators. Info here and herec) You seem to think C++ behaves like C# or Java. There's no garbage collection or other fancy memory management going on in the background. Just raw memory allocation and deallocation with some locking when requesting from different threads.CheersDark Sylinc   