Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Languages / Managed C++ / May 2005

Tip: Looking for answers? Try searching our database.

Recursion problems in .NET

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Ioannis Vranos - 19 May 2005 04:31 GMT
The following code is supposed to print all folder names of a folder but it does not work.
Why?

Change the folder in main() to a folder suitable for your system so as to test it.

I created this proof-of-concept example, because I encountered similar recursion problems
in a more complex project.

#using <mscorlib.dll>

// Displays the full names of all contained folders and subfolders *recursively*
void DisplayFolderNames(System::String *folderName)
{
    using namespace System;
    using namespace System::IO;

    DirectoryInfo * const dir= __gc new DirectoryInfo(folderName);

    if(!dir->Exists)
     return;
   
    // Print contained folder names
    DirectoryInfo *dirDirects[]= dir->GetDirectories();

    if(dirDirects->Count== 0)
     return;
   
    for(long i=0; i<dirDirects->Count; ++i)
    {
        Console::WriteLine("{0}", dirDirects[i]->FullName);

        DisplayFolderNames(dirDirects[i]->FullName);
    }
   
}

int main()
{
    DisplayFolderNames(S"D:\\extract\\temp");
}
Ioannis Vranos - 19 May 2005 04:43 GMT
> The following code is supposed to print all folder names of a folder but
> it does not work. Why?
[quoted text clipped - 38 lines]
>     DisplayFolderNames(S"D:\\extract\\temp");
> }

My mistake, the code above works. However my "real one" still does not. I will try to
split it into threads though.

Can we avoid stack overflows by splitting recursion to multiple threads?
Carl Daniel [VC++ MVP] - 19 May 2005 05:12 GMT
> Can we avoid stack overflows by splitting recursion to multiple
> threads?

In a few cases, yes, but it's probably not a good soluition.

The default stack size is 2mb.  If you're recusing so deeply that you're
consuming 2mb of stack space, there's probably something wrong with your
design.  You could just make the stack bigger (if you create a new thread),
but if you're consuming 3mb with today's test case, who's to say that you
won't need 4mb tomorrow? or 10mb or 100mb?

I really wouldn't expect the code you posted to have any problems with
exhausting the stack space - it should be consuming only a few (two dozen?)
bytes of stack per recursion.

-cd
Willy Denoyette [MVP] - 19 May 2005 08:46 GMT
>> Can we avoid stack overflows by splitting recursion to multiple
>> threads?
[quoted text clipped - 12 lines]
>
> -cd

Carl,

Sorry to correct you, but the default stack for thread/fibers in Win32 is
1MB, check the CreateThread API ins the SDK docs.

Willy.
Ioannis Vranos - 19 May 2005 10:01 GMT
Thank you all for the information, in the end the recursion problem was a bug in my code.
Carl Daniel [VC++ MVP] - 19 May 2005 14:42 GMT
> Carl,
>
> Sorry to correct you, but the default stack for thread/fibers in
> Win32 is 1MB, check the CreateThread API ins the SDK docs.

Yep.  No need to be sorry - I just misremembered and didn't bother looking
it up.

-cd

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.