if statement, i need help

hi all pliz someone help me with this phrase, i really dont understand anything even with the book.

If condition
if (x)
do_something;

Code:

---

if(something) {
  //do something
  //e.g. x = x +1;

}

---

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(n == 10) {
  return (0);
}

---

It's a simple logical statement, something you do everyday, if something then I'll do this, if not, then I'll do that.

Etc.

Edit, here is a tutorial on the matter:

http://www.cprogramming.com/tutorial/c/lesson2.html

Don't use exit in if statements, if possible.

Quote:

---

Originally Posted by Elysia

Don't use exit in if statements, if possible.

---

And why not?

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.

But the application needs to clean up before exiting. If you do exit, it has no chance to do so.

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.

Quote:

---

Originally Posted by JFonseka

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.

---

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

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 :p

Quote:

---

Originally Posted by JFonseka

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.

---

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.

Quote:

---

Originally Posted by Elysia

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.

---

So what's the best way to 'exit' then without actually using the function exit?

Plain old return?

Yep, return and error checking.
(Or, alternatively, in C++, throwing.)

Thanks

Quote:

---

Originally Posted by Elysia

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.

---

This is obviously only a problem when the destructors (or other "cleanup methods" such as Close(), Destroy() or whatever these may be called) do something like delete files, write data to registry or close a database connection.

--
Mats

But it also gives another meaning to undefined. Just because it works doesn't mean it's right and bug free. The behaviour can be undefined.
Therefore it is better to always ensure destructors run. It's rooted deep into the language.

However I'm fairly sure that the OP wouldn't have had to worry about any of this, not anytime soon anyways, lol.

True true, but as they say, it's better early than late. It's better to know good practice and start using it rather than later.