A question of indentation!

[Navin]

Nish - Native CPian wrote: if (call1() && call2() && call3() ....) That won;'t work. I am not supposed to call call-n unless call-n-1 returns true! :confused: Why won't that work then? With C++, you have "short-circuit" evaluation - that is, if the first item in an If statement fails, the rest won't even get evaluated. For instance, I have code like this all the time (well, when I'm not using CStrings... :-D) : if(pStr != NULL && strlen(pStr) > 0) { ... } If pStr is NULL, the first condition fails, and the second condition (strlen) won't even be evaluated. No generalization is 100% true. Not even this one.

[James Pullicino]

Nish - Native CPian wrote: Shucks! It always comes down to the basics and theory. If my OOP theory was strong enough I'd not have run into this situation Nish, don't get discouraged. The prime motivation for most of us to learn OOP was because of these things. Don't shy away from OOP. In a few months you will be the one telling others to wrap their functions into objects. C++ Programmers do it in class Drinking In The Sun Forgot Password?

[Daniel Turini]

Excuse me Nish, I can't resist! Post it in the right forum ! :) :) Crivo Automated Credit Assessment

[Chris Maunder]

do {
if (!call1())
break;
if (!call2())
break;
...
} while (false);

Cleanup();

cheers, Chris Maunder

VC++ - the language that doesn't say 'no'

[Jason Gerard]

Nish - Native CPian wrote: PGP calls return a PGPError and you need to call IsPGPError(...) on it to figure out whether it was an error or not. That is the worst API I've ever heard of. Jason Gerard

[Jason Henderson]

I never thought of it this way but try/catch would be a good "control structure" to use instead of nested if's. Its also 100x easier to read. Is Stroustrup trying to say it should only be used as a return mechanism if it isn't used in error handling? Like it or not, I'm right.

[Jason Henderson]

// Bad example, but it shows you how to use them
for (int count=0; count<10; count++)
{
try
{
if (count%2 == 0)
throw "Even";
else
throw "Odd";
}
catch(LPSTR str)
{
MessageBox(NULL, str, "This number is:", MB_OK);
}
catch(...) // all other errors
{
MessageBox(NULL, "Unhandled exception.", "Error", MB_OK);
}
}

Like it or not, I'm right.

[Eddie Velasquez]

Christian Graus wrote: There are therefore legitimate uses of exceptions that have nothing to do with errors. Well, I can't pretend to teach C++ to Bjarne! :-O But as quoted, these "legitimate uses that have nothing to do with errors" are the exception, not the rule. (pun intended!) I'm not really thinking about this too hard, but I fail to come up with a case where I would raise an exception that doesn't somehow indicate an error condition. :confused:

---

Eddie Velasquez: A Squeezed Devil
Checkout General Guidelines for C# Class Implementation

[Eddie Velasquez]

I want to add that it's a bad idea to throw exceptions for anything that doesn't indicate an "exceptional" (uncommon, erroneous) condition because in C++ exception support has a lot of overhead that's too costly for idioms that can be expressed in a cleaner and more efficient way using othe language constructs. Jason Henderson wrote: catch(...) // all other errors { MessageBox(NULL, "Unhandled exception.", "Error", MB_OK); } Just nitpicking... the message should be "unexpected exception" not "unhandled exception" because you just handled the exception!

---

Eddie Velasquez: A Squeezed Devil
Checkout General Guidelines for C# Class Implementation

[Eddie Velasquez]

Jason Henderson wrote: I never thought of it this way but try/catch would be a good "control structure" to use instead of nested if's. Its also 100x easier to read. The problem is that for most implementations, exception support has too much overhead for practical use as a "control structure" that's not directly related to exceptional (uncommon, errroneous) conditions. Check out Vishal Kochhar's excellent How a C++ compiler implements exception handling article for more information.

---

Eddie Velasquez: A Squeezed Devil
Checkout General Guidelines for C# Class Implementation

[Eddie Velasquez]

Yeah I thought about this but I think it's a bad idea. Check out my reasons why this use of exceptions is a bad idea post

---

Eddie Velasquez: A Squeezed Devil
Checkout General Guidelines for C# Class Implementation

[Tomasz Sowinski]

Eddie Velasquez wrote: I fail to come up with a case where I would raise an exception that doesn't somehow indicate an error condition Assume that you have a dozen of functions searching for some data in smart card, registry, current directory, directories listed in some env variable, etc, etc. So instead of nested constructs like this...

if (!SearchForFooInGoo(...))
{
if (!SearchForFooInBoo(...))
{
}
}

... you just throw FooFoundException when one of the calls returns true. Then your exception handler does the job. Perverse, but still possible :-D Tomasz Sowinski -- http://www.shooltz.com

- It's for protection
- Protection from what? Zee Germans?

[Jason Hooper]

Nish - Native CPian wrote: In fact code that is not indented is an absolute pain to even look at. But then sometimes you get into absurd levels of indentation Try generating HTML tables with perl's CGI.pm. (Yes I'm using the MDE to edit perl files... this was before I learned vi) - Jason (SonorkID 100.611) In the beginning, teachers taught the 5 W's: who, what, where, when, why. Now it's just a big damn G

[Tomasz Sowinski]

I don't buy performance-related arguments, at least not in 100%. While there are the situations in which this could matter (thight loops etc), in my example you'd access disk. For sure this operation would be orders of magnitude slower than throwing/catching exceptions. The same applies to displaying anything on the screen or accepting user input. In short, the cost associated with exception handling would be totally invisible. Tomasz Sowinski -- http://www.shooltz.com

- It's for protection
- Protection from what? Zee Germans?

[Andreas Saurwein]

Jason Gerard wrote: That is the worst API I've ever heard of Try Windows ;) ERROR_MORE_DATA Well, actually you have the same kind of return values in almost any API - commonly you find this things in "evolved" API's where conditions changed but not the environment. Thus, the function returns a error which must be interpreted to find out that its actually just a information. Sometimes its just a misconception as for ERROR_MORE_DATA. Vote against software patents in europe

[Tomasz Sowinski]

What about this? :)

switch (1)
{
case 1: if (!call1()) break;
case 2: if (!call2()) break;
case 3: if (!call3()) break;
...
}

Tomasz Sowinski -- http://www.shooltz.com

- It's for protection
- Protection from what? Zee Germans?

[Nish Nishant]

Eddie Velasquez wrote: but OOP you must. Yeah. I am gonna OOP more from now on ... Nish :-)

---

Regards, Nish Native CPian. Born and brought up on CP. With the CP blood in him.

[Nish Nishant]

Thanks Chris M. PeterChen had already suggested this to me. Though he used a 0 instead of a false as you did :-) By the way your do while brace-poitioning is ugly Dont use do { like a java guy. Put it as do { like a C++ guy Nish

---

Regards, Nish Native CPian. Born and brought up on CP. With the CP blood in him.

[Nish Nishant]

That was indeed innovative Tomasz :-) Nish

---

Regards, Nish Native CPian. Born and brought up on CP. With the CP blood in him.

[Eddie Velasquez]

Tomasz Sowinski wrote: While there are the situations in which this could matter (thight loops etc), in my example you'd access disk As everything in software development there's no such thing as an absolute certainty. That's why I used the word "usually". And I still believe it's a bad idea to getting used to use exceptions for other things besides error handling. Tomasz Sowinski wrote: In short, the cost associated with exception handling would be totally invisible. Remember the cost of exceptions isn't only related to speed, size matters too! (Doesn't matter what some women say :-O ;))

---

Eddie Velasquez: A Squeezed Devil
Checkout General Guidelines for C# Class Implementation