   Application Level Memory Mangement
 ArticleAuthor: David Lovegrove (ace_lovegrove@hotmail.com) ace_lovegrove on our forums.FogBugz case number: 14871Initial impressions: Not so hot, but he means well. There's not a lot of information here, but it could be salvagable with a narrowing of focus.   
  Language is a little awkward, e.g. "there is never a time when it is unimportant" he should remove the double negative. I also have alarm bells ringing because he's saying it's a series rather than a standalone article - what he's provided is very short and I suspect we'd be better off asking him to submit it all as one article instead of as a series.From a technical standpoint, three issues to start him off:He's relying on the implementation of 'malloc' putting the size in the four bytes prior to the memory block. I'm not sure how portable that is; at the very least he should explain it.While his placement new operator seems to allow the memory block to be allocated by a specific heap, there's no obvious way to deallocate again (delete only touches the global current heap).Something's very wrong with his test output. The code says he's allocating/deallocating 4 bytes, but the output says 400. (The test output should probably be simple text instead of an image, too).   ;  Rejection sent, bcc'd to editor@gamedev.net. Contents as follows:Quote:Dear David Lovegrove,We greatly appreciate your submission of "Application Level Memory Management" for publication consideration. Unfortunately we are not able to accept this submission for publication, as there are a large number of technical issues with the article. Roughly in order of appearance:    * The class _heapbase exists in the global scope, but begins with an underscore. Such identifiers are reserved for the compiler.    * The need for the _heapbase base class is not adequately explained.    * Your version of new returns 0 when malloc() returns 0 instead of throwing a std::bad_alloc exception.    * The new operator never calls the new handler.    * No overload of nothrow new.    * getallocsizefromptr() relies on the size of the allocation being placed in the four bytes in front of the allocation. This is severely non-portable as not all malloc() implementations store the size allocated in that location, and not all malloc() implementations store the exact size allocated; instead storing the size rounded up to the next multiple of four or eight, etc. A better solution would be to use _msize() or malloc_usable_size(), depending on the standard C library implementation to get size from this pointer, and use this size in both allocation tracking and deallocation tracking.    * The try/catch block in heapsimple::freeup() doesn't do what you say it does.    * operator new will segfault if called before the initialization function is called, which can happen with global variables that request memory on initialization such as many containers.    * A placement version of operator new is declared without the corresponding version of operator delete.    * There is no apparent justification for the inclusion of the placement version of new nor is the use of the placement form explained.    * There is no justification for the infinite loop in the test application.    * The test application's output does not match what the expected values would be based on the test application's source code.    * The definition of "page" used in the conclusion does not conform to the definition of page commonly used in memory management.    * There is no discussion of the drawbacks of overloading the global new and delete operators.Should it be possible to resolve any of these outstanding considerations, we would be happy to review your content again. For a more detailed explanation of the aforementioned reasons, or to answer any of your questions in general, please contact the Editor-in-Chief at editor@gamedev.net.Thank you for your submission, and we hope that you will again choose GameDev.Net for future content you wish to share with the game development community.As you might know, GameDev.Net receives a large number of article submissions and I do apologize for any delay in getting back to you.Howard Jeng, GDERB Editor-in-Chief (acting)