Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / Exiting application from a function

Author
Message
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 14th Apr 2008 19:45
I was wondering if it was possible to exit the program from within a function. Is there a command that will exit the program so that return does not have to be manually used within the main or darkgdk function?
Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 14th Apr 2008 21:18
There is the exit(int condition) function. I'd use it advisedly as any c++ space that you may have allocated may need to be de-allocated.

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 14th Apr 2008 22:26
Use the function PostQuitMessage.
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 14th Apr 2008 23:13 Edited at: 14th Apr 2008 23:13
Problem with 'PostQuitMessage' is that it runs through from that point onwards all of the code until it reaches the end; if it encounters a never ending loop it will loop until manually closed.

'Exit' seemed to work fine. What is the difference between that and using the 'return' function in the main block of code?
jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 14th Apr 2008 23:42
I still maintain that you should use PostQuitMessage, and return from your routine that has run into trouble.

The difference is that with exit, you do not release any resources, and therefore, you will leak memory and resources.
Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 14th Apr 2008 23:48
That would be a concern of mine. I would question what happens with resources that were part of program space when the program was exited. Would Windows recoup them automatically since, theoretically, it's what allocates the resources to begin with?

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 14th Apr 2008 23:56
To be on the safe side and keep things simple I'll just go with 'PostQuitMessage' and have a global variable 'bRunning' initially set to true. When PostQuitMessage is used, bRunning is changed to false and the while loop looks like this: 'while(bRunning == true)'. That solves the problem of eternal looping.
Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 15th Apr 2008 00:04
As a matter of completeness on the subject I will add that you can specify more than one call to the atexit() function that lets you build a list of functions to call when the program exits. Unfortunately it may be difficult to know exactly what needs to be cleaned up, if anything, from the point at which you exit.

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
Ghthor
16
Years of Service
User Offline
Joined: 5th Apr 2008
Location:
Posted: 15th Apr 2008 01:38
I believe that all destructors are called on outstanding classes when the program exits; if you handle all memory allocation inside the classes and have the destructor's dealloc all the memory then it will clean itself all up.

Taco Justice
Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 15th Apr 2008 02:59
That's what I've never been sure of. I really don't have the heart to study that deeply. The destructors activate when the object goes out of scope. That could be when a function exits or a block in which a class object closes. But if you were to exit() would it unfold back through all the function calls or would it jump to some pre-determined point with a specific stack state and skip going through all the points at which destructors would be called?

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 15th Apr 2008 03:04
Quote: "The difference is that with exit, you do not release any resources, and therefore, you will leak memory and resources."

To my knowledge, the OS automatically frees memory used by the process when it exits. Nonetheless, it's good practice to free resources yourself.

jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 15th Apr 2008 03:24
No, it doesn't. That's why I've said what I've said. This is standard Windows programming practice. You don't just end an app when you feel like it.

Yes, you will get your heap back...that's C, not Windows.

You will leave your window class orphaned, and also not all DLL linkages will be automatically severed, so you might also orphan a DLL, and any extra stuff you've created.

There's alot to it, actually, but that is why we have PostQuitMessage in the first place.
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 15th Apr 2008 05:13
Quote: "No, it doesn't."

Well in that case I'm not sure how memory magically gets freed when this application exits:



According to MSDN, when terminating a process any resources allocated by the process are freed. What does it mean by that?

jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 15th Apr 2008 05:30 Edited at: 15th Apr 2008 05:36
That doesn't cover everything. Not nearly. You can cherry pick all you want, but you will not find a reference that states that all resources are automatically released.

In fact, you will find that Microsoft often warns you that you must explicitly free resources such device contexts, GDI objects, DLLs, and anything that uses reference counting.

Whatever, go ahead and do it anyway that suits you.

BTW, read that link!

That's not even a Windows app, either. Benjamin, you're a smart guy, but you are wrong about this.
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 15th Apr 2008 06:19
Oh, a little misunderstanding I think. When I posted that code I was just referring to general memory allocations, nothing else. I do believe what you're saying is true.

jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 15th Apr 2008 07:21
Yes, I agree about that. Sorry for the confusion.
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 21st Apr 2008 21:12
c# related slightly off topic kinda
I have a question folks. When you use C#, not all classes, objects etc. have a destructor or anything you can call. I read in a MSCRM referernce how nothing is done to free your resources for you. (Context is a main program, calls your DLL which has a calling convention you follow for it to work).
How do you free these?

C++ take
Yeah, I agree with Jenzai, however when I'm developing in VS2008 studio with my DARK GDK... I found the "proper" EXIT VERY VERY painfully slow! So what I do is disable the escape key, and when I want to stop my app, I ALT-TAB to VS2008, and press SHIFT+F5 (Stop Debugging).

Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 21st Apr 2008 22:23 Edited at: 21st Apr 2008 22:27
Since C# is relatively new to me all I can say is that objects are supposed to be removed when they go out of scope, though the garbage collection to recover the memory it took up may not run immediately. Garbage collection can be forced however.

Since you create many objects using the new keyword you can also delete them using the delete keyword.

MyClass myObject = new MyClass();

delete myObject;

There are ways of controlling scope depending on your needs. The other day I wrote my first C# program in months used a usingconstruct to create and dispose of a streamwriter object each time through a loop.

BTW, what kind of objects did you have in mind?

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 21st Apr 2008 22:36
C# Related
Well... for the C# thing...
Quote: "Error 1 The type or namespace name 'delete' could not be found (are you missing a using directive or an assembly reference?)"


delete isn't an option. SOME Objects have a method IDestroy or some such nonsense -its not seen enough to where I care about it. Like you said, they are supposed to go out of scope and get cleaned later. Also you CAN invoke the garbage collector yourself... no I don't know how.. but I read about it enough to know it could be done if I ever needed it.

The objects I would make in this context would all be C# stuff... but the Microsoft docs mentioned what I said before. and we did notice over time the server would slow, and reboot would fix. Just curious.

Generally Speaking
I don't mean to hijack the thread.

C++ Exiting C++ when you want it to can be a pain. for sure.. but when you write your class correctly, they should shutdown ok.. but even that gets complicated when this class uses that class, but that class references this one. Depending on complexity, measures need to be taken to assure clean Instantiation and Destruction! (Sounds so Genesis & Revelations doesn't it?)

Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 21st Apr 2008 22:54
Quote: "SOME Objects have a method IDestroy or some such nonsense"


You're probably talking about IDisposable which is an interface to guarantee that the programmer creates a destructor for the class. There's also the Dispose() function which I haven't delved into very much. I've relied on the system to do the work for me.

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 21st Apr 2008 23:03
Quote: "I was wondering if it was possible to exit the program from within a function."

Back to C++ - Don't use raw pointers, make everything exception safe, then put a try/catch around your main loop and throw an exception.

If your objects are exception safe and you are using smart pointers where you do have pointers then everything will be destroyed correctly, and execution will jump to your outer catch block where you can finish cleaning up everything else.

Obviously though, that's easier to say/write than it is to do.

jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 21st Apr 2008 23:19
Things that require that are usually noted as such. In a typical COM scenario, they are reference counted at some level. Release the interface after cleaning up what you've created to support it.

You should never have to do this, but IUnknown has Release, so every COM object can have its reference count decremented using that, whether it exposes a Release member function, or not.

You should run memory leak detection software on that code that requires the mysterious reboot fix. If your application is leaking memory, you will not always get any indication of that, until you start getting those symptoms.

Please don't use Biblical references in your posts; that's offensive to me, and it violates the AUP.
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 22nd Apr 2008 01:07
Thanx for your reply about the server issue.

Quote: "Please don't use Biblical references in your posts; that's offensive to me, and it violates the AUP. "
I don't know how what I said was offensive or anything or AUP breaking but I didn't mean to offend anyone. If I have offended you, I apologize.

Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 22nd Apr 2008 09:27 Edited at: 22nd Apr 2008 09:29
Ignore this...

Login to post a reply

Server time is: 2024-11-20 07:31:08
Your offset time is: 2024-11-20 07:31:08