hi all pliz someone help me with this phrase, i really dont understand anything even with the book.
hi all pliz someone help me with this phrase, i really dont understand anything even with the book.
Suppose you want to check if a number is equal to 10 during the running of a program, and if that number is 10, to exit:Code:if(something) { //do something //e.g. x = x +1; }
It's a simple logical statement, something you do everyday, if something then I'll do this, if not, then I'll do that.Code:if(n == 10) { return (0); }
Etc.
Edit, here is a tutorial on the matter:
http://www.cprogramming.com/tutorial/c/lesson2.html
Last edited by JFonseka; 04-15-2008 at 04:54 AM.
=========================================
Everytime you segfault, you murder some part of the world
Because you will prematurely exit a program.
It's better to return an error from functions to let them handle the error as appropriate, and if they can't handle it, they will return an error, etc, until main which will exit gracefully.
Exit will also cause any memory or cleanup that needs to be made unmade.
I see, but once a program exits though, it's not running in the task manager anymore, so it can't be using any memory.
=========================================
Everytime you segfault, you murder some part of the world
Clean up what exactly? I was under the impression that once a program exits abnormally even if stray values are left in memory since they aren't being used by the program they are free to be overwritten.
When you run a program, like a game or something you can see the jump on taskmanager like several hundred megabyte's depending on what type of game it is, and then if it causes an illegal operation and shutsdown all that memory is freed and the RAM meter goes right down again.
=========================================
Everytime you segfault, you murder some part of the world
Yes, this has been debated before:
1. Memory allocations ARE cleaned up by all major commercial OS's when the application exits. Small OS's, such as RTOS's and such may not even support processes as such, and may certainly not do any cleanup - it's up to the developer to make sure no memory leaks happen.
The same applies to file-handles, semaphores, shared memory and similar: Windows, Linux etc will close files and clean up any open system resources.
2. There are other resources that may NOT be cleaned up: temporary files created by the application, global resources that specifically are noted to NOT be cleaned up by the OS [can't think of one right now, but at least some OS's have those].
Arbitrary calls to exit is a bad strategy for error handling, mostly because it makes the assumption that nothing else will be important to do if this function is failing - which is probably OK in a small program, but in bigger programs, the possibility of something going horribly wrong because of a random exit is increasing.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Ah...my bad. Well it's a good thing Elysia brought this up because I was doing an assignment and I did exactly that and the specification was to handle errors appropriately
=========================================
Everytime you segfault, you murder some part of the world
Files may not be closed. Proper information may not be saved. Proper data into registry may not be saved (remember: many programs saves settings only at exit!). State of databases may not be closed correctly (database has no chance to do termination work), etc, etc, etc.
In C++, it's even worse because destructors won't necessarily be run. That means all that cleanup code won't be run.
In short, it's a very bad idea.
Thanks
=========================================
Everytime you segfault, you murder some part of the world