is there a memory limitation for MFC programs?
-
the following is part of code from Nero SDK (NeroCmd), which recursively generate a ISO tree for buring, the main concept is finding all subfolder & folders of passed in directory "psFilename", this code works fine under console mode, but when I tried to put it to my MFC project my program always auto close due to it, but sometimes my code could get through without any modification, anybody knows what is going on here? is that because there's a memory limitation for MFC dialog application, due to the recursion here. CExitCode CBurnContext::CreateIsoTree (const PARAMETERS & params, LPCSTR psFilename, NERO_ISO_ITEM ** ppItem, int iLevel) { // CFindFiles is a helper class for file and subdirectory handling CFindFiles ff (psFilename); *ppItem = NULL; if (!ff.IsValidEntry()) { if (0 == iLevel) { // If we haven't found any entries and we are on the // first level of recursion then this should be // reported as an error. m_ErrorLog.printf ("File specification '%s' resulted in no matches!\n", psFilename); return EXITCODE_FILE_NOT_FOUND; } else { // If we are on a level other than first, it is ok // not to find any entries. This simply means we // stumbled upon an empty directory somewhere in a tree. return EXITCODE_OK; } } char sPath[MAX_PATH]; // Make sure that we have no relative path names, but only absolute paths if (NULL == _fullpath (sPath, psFilename, sizeof (sPath))) { // Our path buffer is too small. Bail out! return EXITCODE_INTERNAL_ERROR; } // Find the last blackslash and remove it if found. // This will leave us with a root directory. LPSTR psBackslash = strrchr (sPath, '\\'); if (NULL != psBackslash) { *psBackslash = '\0'; } do { std::string sNewPath; sNewPath = sPath; sNewPath += "\\"; sNewPath += ff.GetName (); if (ff.IsSubDir()) { // Here we handle subdirectories // strcmp returns 0 on equal strings. // Proceed if name contains none of "." or ".." if ((0 != strcmp (ff.GetName (), ".")) && (0 != strcmp (ff.GetName (), ".."))) { // Append a wildcard to the path and do a recursive search. sNewPath += "\\"; sNewPath += ff.GetWildcard (); NERO_ISO_ITEM * pNewItem = NeroCreateIsoItem (); if (NULL == pNewItem) { DeleteIsoItemTree (*ppItem); return EXITCODE_OUT_OF_MEMORY; } // Attach this item to the beginning of the list. if (*ppItem != NULL) { pNewItem->nextIte
-
the following is part of code from Nero SDK (NeroCmd), which recursively generate a ISO tree for buring, the main concept is finding all subfolder & folders of passed in directory "psFilename", this code works fine under console mode, but when I tried to put it to my MFC project my program always auto close due to it, but sometimes my code could get through without any modification, anybody knows what is going on here? is that because there's a memory limitation for MFC dialog application, due to the recursion here. CExitCode CBurnContext::CreateIsoTree (const PARAMETERS & params, LPCSTR psFilename, NERO_ISO_ITEM ** ppItem, int iLevel) { // CFindFiles is a helper class for file and subdirectory handling CFindFiles ff (psFilename); *ppItem = NULL; if (!ff.IsValidEntry()) { if (0 == iLevel) { // If we haven't found any entries and we are on the // first level of recursion then this should be // reported as an error. m_ErrorLog.printf ("File specification '%s' resulted in no matches!\n", psFilename); return EXITCODE_FILE_NOT_FOUND; } else { // If we are on a level other than first, it is ok // not to find any entries. This simply means we // stumbled upon an empty directory somewhere in a tree. return EXITCODE_OK; } } char sPath[MAX_PATH]; // Make sure that we have no relative path names, but only absolute paths if (NULL == _fullpath (sPath, psFilename, sizeof (sPath))) { // Our path buffer is too small. Bail out! return EXITCODE_INTERNAL_ERROR; } // Find the last blackslash and remove it if found. // This will leave us with a root directory. LPSTR psBackslash = strrchr (sPath, '\\'); if (NULL != psBackslash) { *psBackslash = '\0'; } do { std::string sNewPath; sNewPath = sPath; sNewPath += "\\"; sNewPath += ff.GetName (); if (ff.IsSubDir()) { // Here we handle subdirectories // strcmp returns 0 on equal strings. // Proceed if name contains none of "." or ".." if ((0 != strcmp (ff.GetName (), ".")) && (0 != strcmp (ff.GetName (), ".."))) { // Append a wildcard to the path and do a recursive search. sNewPath += "\\"; sNewPath += ff.GetWildcard (); NERO_ISO_ITEM * pNewItem = NeroCreateIsoItem (); if (NULL == pNewItem) { DeleteIsoItemTree (*ppItem); return EXITCODE_OUT_OF_MEMORY; } // Attach this item to the beginning of the list. if (*ppItem != NULL) { pNewItem->nextIte
Default stack size is the same for MFC apps vs console apps (1MB if I remember correctly). However with an MFC app, you'll find much more of your stack being used by MFC itself. The console app doesn't have this overhead which is why it was running OK. Also, if you're running a debug build, a lot of the stack is being used by all the debugging info. Since you're pretty close, fails sometimes and not others, you could probably just bump up your stack size a bit and be OK. This is done via a link option, covered in MSDN here[^]. Another option would be to dump this code out into a worker thread, which will have it's own stack and won't have the MFC overhead using alot of it. ----- In the land of the blind, the one eyed man is king.