Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. Memory Managers with C, C++ and MFC

Memory Managers with C, C++ and MFC

Scheduled Pinned Locked Moved C / C++ / MFC
csharpc++announcementvisual-studiodata-structures
1 Posts 1 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • P Offline
    P Offline
    Patje
    wrote on last edited by
    #1

    Managing memory (leaks and overwrites) was quite easy when were using plain C. We just had to define malloc(size) and free(ptr) to point to our own OurMalloc(size) and OurFree(ptr). From that moment on we could add wonderful stuff to OurMalloc and OurFree like pooling memory chunks, checking for overwrites (using red zones before and after the allocated areas), checking for leaks, even storing the call stack at the moment of the malloc so a decent memory leak could be reported at the end of the program. Then came C++. This was a bit more difficult since we now also had to reroute the new and delete operator. But after some investigation we found out how to implement those operators to forward their calls again to OurMalloc and OurFree. Then came MFC. MFC (we use the most recent Visual Studio .Net) does not like the redirection of the global new and delete. You get all kinds of nice linking errors and warnings and even if you succeed in compiling it, you're guaranteed to have run-time crashes because your own new and delete is used instead of the MFC ones --> BIG PROBLEM. So we end up with our old plain C code using our own advanced memory manager, and the C++ code (using MFC) that uses the MFC memory manager. That's not the only problem: once in a while, our defines of malloc and free causes problems if an external include file (of the compiler or a 3rd party) has a method free defined in a class and it is called in an inline method. Then our own OurFree is called instead of the class's free method --> BIG PROBLEM. I tried to look up methods of using custom memory allocators but only find methods that can only be used in a debug version (e.g. malloc_dbg, _CrtSetAllocHook, DEBUG_NEW, ...) and no method that works in release executables as well. What I want to obtain is the following:* Having a memory manager that performs memory pooling (in debug and release builds), checks for overwrites, leaks and reports the call stack for leaks (in debug builds). External tools like Purify often give rubbish output so that's not an option to check for leaks.

    • Having a memory manager that can be used for plain C calls (malloc,free) and C++ new and delete 'calls' with and without MFC. Is there a good article on how to add a custom memory manager to C/C++/MFC? Are there any good commercial or freeware or open source memory managers that perform these tasks and can be used with plain C, C++ and MFC? Thanks for your input. Enjoy life, this is not a
    1 Reply Last reply
    0
    Reply
    • Reply as topic
    Log in to reply
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes


    • Login

    • Don't have an account? Register

    • Login or register to search.
    • First post
      Last post
    0
    • Categories
    • Recent
    • Tags
    • Popular
    • World
    • Users
    • Groups