Fix for the Memory Manager disabling macros
by Justin Boswell · 08/08/2004 (7:23 am) · 9 comments
The Torque Memory Manager is a fairly nifty little block of code and it's great for debugging memory fun (as seen here), but I prefer to just use the OS routines for memory allocation in production, mostly for performance. The GG guys put a macro (TORQUE_DISABLE_MEMORY_MANAGER) in place to make this possible. Unfortunately, at some point bits of code wound up in places where they are not controlled by this macro, and they break your build horribly if you try disabling the memory manager.
To fix this, use the following 2 patches. First in platform/platformMemory.cpp:
Note: The GG forum code was a bit overzealous with trying to encode my apostrophes, make sure you fix that if you intend to use these patches with patch(1). The changes are small enough that you can do them by hand with no trouble anyway.
And next in platformWin32/winMemory.cpp:
Now, you can just put a #define TORQUE_DISABLE_MEMORY_MANAGER in platform/platform.h somewhere near the top, (I usually put macros after the first set of includes) and rebuild. Now you'll be using the OS defined routines instead, and you won't get the dreaded "I can't find the 'new' operator anywhere" error message.
To fix this, use the following 2 patches. First in platform/platformMemory.cpp:
Note: The GG forum code was a bit overzealous with trying to encode my apostrophes, make sure you fix that if you intend to use these patches with patch(1). The changes are small enough that you can do them by hand with no trouble anyway.
--- platformMemory.cpp.old 2004-08-05 09:20:25.894268800 -0400
+++ platformMemory.cpp 2004-08-05 09:26:45.470072000 -0400
@@ -8,10 +8,6 @@
#include "console/console.h"
#include "platform/profiler.h"
-//-------------------------------------- Make sure we don't have the define set
-#ifdef new
-#undef new
-#endif
enum MemConstants {
Allocated = BIT(0),
@@ -1082,10 +1078,10 @@
#if !defined(TORQUE_DISABLE_MEMORY_MANAGER)
-
-
-
-
+//-------------------------------------- Make sure we don't have the define set
+#ifdef new
+#undef new
+#endif
// Manage our own memory, add overloaded memory operators and functionsAnd next in platformWin32/winMemory.cpp:
--- winMemory.cpp.old 2004-08-05 09:38:52.505497600 -0400
+++ winMemory.cpp 2004-08-05 09:43:00.542156800 -0400
@@ -4,7 +4,7 @@ //-----------------------------------------------------------------------------
#include "platformWin32/platformWin32.h"
-
+#include "platform/platform.h"
void* dMemcpy(void *dst, const void *src, unsigned size)
{
@@ -30,11 +30,11 @@ return memcmp(ptr1, ptr2, len);
}
-
+#if !defined(TORQUE_DISABLE_MEMORY_MANAGER)
#ifdef new
#undef new
#endif
-
+#endif /* TORQUE_DISABLE_MEMORY_MANAGER */
#if defined(TORQUE_COMPILER_MINGW)
#include <stdlib.h>Now, you can just put a #define TORQUE_DISABLE_MEMORY_MANAGER in platform/platform.h somewhere near the top, (I usually put macros after the first set of includes) and rebuild. Now you'll be using the OS defined routines instead, and you won't get the dreaded "I can't find the 'new' operator anywhere" error message.
#2
08/11/2004 (9:42 am)
#3
08/11/2004 (9:45 am)
Yes, there is a performance increase. Not a huge one, but in modules that work heavily with dynamic memory allocation, the boost is noticeable. While we only develop for Windows, the effect should be present everywhere, as you are removing complex wrapping code from a basic, oft-used operation that the OS should be able to do very efficiently. Torque's memory manager's job is to make memory allocations easy to trace down and debug. If you don't need this functionality, then it is always best to simplify your code paths.
#4
08/16/2004 (2:17 pm)
Torque's memory manager can also be advantageous if getting memory from the OS is a particularly heavy process. It once was, and you never know then the problem will pop up again (porters take note ;).
#5
04/26/2005 (4:47 am)
gives memory error with 1.3 ..... need some changes to the code i think .....
#6
08/26/2005 (8:20 pm)
After applying these patches, I get a clean compile but cannot figure out how to link. Using VC++7. Is there some special projections to enable STL support or something?------ Build started: Project: T2D, Configuration: Debug Win32 ------ Linking... compiler.obj : error LNK2019: unresolved external symbol "void * __cdecl operator new(unsigned int,void *)" (??2@YAPAXIPAX@Z) referenced in function "struct BreakStmtNode * __cdecl constructInPlace<struct BreakStmtNode>(struct BreakStmtNode *)" (??$constructInPlace@UBreakStmtNode@@@@YAPAUBreakStmtNode@@PAU0@@Z) consoleInternal.obj : error LNK2001: unresolved external symbol "void * __cdecl operator new(unsigned int,void *)" (??2@YAPAXIPAX@Z) materialList.obj : error LNK2001: unresolved external symbol "void * __cdecl operator new(unsigned int,void *)" (??2@YAPAXIPAX@Z) guiMLTextCtrl.obj : error LNK2019: unresolved external symbol "void * __cdecl operator new(unsigned int,void *)" (??2@YAPAXIPAX@Z) referenced in function _$E8 ../example/T2D_DEBUG.exe : fatal error LNK1120: 1 unresolved externals Build log was saved at "file://c:\Torque2D\Sdk\engine\out.VC6.DEBUG\BuildLog.htm" T2D - 5 error(s), 0 warning(s)
#7
01/23/2006 (10:25 pm)
Is this needed for TGE 1.4 or was it fixed? 
#8
06/07/2006 (1:30 pm)
Bet it's hard to check, Jonathon.
#9
06/07/2006 (2:32 pm)
Bet it's hard not to post condescending posts, Stefan 
Torque Owner Stephen Clark
-s