A question of indentation!

[Nish Nishant]

Navin wrote: If pStr is NULL, the first condition fails, and the second condition (strlen) won't even be evaluated. PGP calls don't return true/false/1/0. They return a PGPError type. We gotta call IsPGPError() on the return value to figure out if it's an error. On some occasions an error is permissible. Like if we have a call that works only with DSS keys, then if it fails for an RSA key it's not really an error. Nish

---

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

[Jorgen Sigvardsson]

Some people use goto :~ for this kind of stuff. Basically it works something like this:

if(someCondition) {
   // acquire some resources...
   // some error is detected - bail out
   goto cleanup\_1;
}

if(someOtherCondition) {
   // acquire some more resources...
   // some error is detected - bail out
   goto cleanup\_2;
} 

// perhaps some more code

return true; // for success

cleanup_2:
// cleanup resources acquired up to "goto cleanup_2"
cleanup_1:
// cleanup resources acquired up to "goto cleanup_1"
return false; // for failure

This is the only instance where I'm prepared to defend the usage of goto's. It's fast (no exception handling overhead), it's not spaghetti code and it's quite readable! Sonorked as well: 100.13197 jorgen FreeBSD is sexy.

[Tomasz Sowinski]

Eddie Velasquez wrote: Remember the cost of exceptions isn't only related to speed, size matters too! So how much bigger my program will be if I replace multiple nested ifs with try/throw/catch? Assuming that you're using exceptions to catch 'real' errors the difference is zero. Tomasz Sowinski -- http://www.shooltz.com

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

[Jorgen Sigvardsson]

Nish - Native CPian wrote: I like your do while(0) idea do { } while(0) is a really cool technique, especially with macros. It is easy to mistype macros in such ways that they look syntactically correct, but expanded they wreak havoc. Consider this:

#define RET_IF_FAIL(x) if(FAILED(x)) return

if(someCondition)
RET_IF_FAIL(m_pObject->DoTheChokaChoka());
else
MessageBox(NULL, "someCondition not met", "Status report", MB_OK);

The else will be connected to your "hidden if" inside RET_IF_FAIL which is clearly not the intent. The expanded code will look like:

if(someCondition)
if(FAILED(m_pObject->DoTheChokaChoka())) return;
else
MessageBox(NULL, "someCondition not met", "Status report", MB_OK);

Scary stuff! I've had my fair share of these bloody mistakes! Solution? Keep on reading:

#define RET_IF_FAIL(x) do { if(FAILED(hr)) return; } while(0)
if(someCondition)
RET_IF_FAIL(pObject->DoTheChokaChoka());
else
MessageBox(NULL, "someCondition not met", "Status report", MB_OK);

This is much better since the "hidden if" is wrapped inside a block which has an associated language construct - the do while. Thus the if nor the block cannot be "misconnected". The expanded code will be:

if(someCondition)
do { if(FAILED(m_pObject->DoTheChokaChoka())) return; } while(0);
else
MessageBox(NULL, "someCondition not met", "Status report", MB_OK);

And the best part is that a do { } while(0) is totally costless! The compiler will optimize away the loop expression/jump so that it will not add any extra garbage to your code. Sonorked as well: 100.13197 jorgen FreeBSD is sexy.

[Eddie Velasquez]

Tomasz Sowinski wrote: So how much bigger my program will be if I replace multiple nested ifs with try/throw/catch? Assuming that you're using exceptions to catch 'real' errors the difference is zero. It depends. A lot of factors come into play, obvious ones: if you define variables with ctors and dtors between the ifs and if the code is templated. As I said before: it all depends on the particular case. In some scenarios even the use of exceptions for error reporting is overkill. For most developers getting into the habit of misusing exceptions (or templates or whatever relatively obscure language feature) makes them produce bad code. I'm not saying that you or me will produce buggy or bad code (we don't write buggy code, do we? ;) ) But the average developer is so lame that (s)he acts like a robot without really thinking about the code (s)he is writing and the consecuences of the design decisions made.

---

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

[Tomasz Sowinski]

Eddie Velasquez wrote: In some scenarios even the use of exceptions for error reporting is overkill. Hard real time systems controlling nuclear reactors, yes. But not for majority of non-embedded stuff. Anyway, Standard C++ uses exceptions for basic functionality, like reporting failures from new operator. Your code already has exception frames set. Eddie Velasquez wrote: But the average developer is so lame that (s)he acts like a robot without really thinking about the code (s)he is writing and the consecuences of the design decisions made. So it's better to have dozen of nested ifs and 'manual' cleanup code? C'mon :) Tomasz Sowinski -- http://www.shooltz.com

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

[Eddie Velasquez]

Tomasz Sowinski wrote: Hard real time systems controlling nuclear reactors, yes. No need for exageration. Tomasz Sowinski wrote: Standard C++ uses exceptions for basic functionality, like reporting failures from new operator. Not Visual Studio. At least version 6.0 Tomasz Sowinski wrote: So it's better to have dozen of nested ifs and 'manual' cleanup code? C'mon More exageration. When a function is overly complex you split it in managable units. Destructors were invented for cleanup. Why did you quote the word 'manual'? I don't recall mentioning manual cleanup code. :confused: I've never advocated writing spagetti code or not using exceptions or templates or whatever in my code. Just use 'em where they should be used and try hard not to grow bad habits.

---

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

[Ravi Bhavnani]

How about:

if (call1() && call2() && call3() &&
call4() && call5() && call6()) {
// Success
} else {
// Error
}

/ravi "There is always one more bug..." http://www.ravib.com ravib@ravib.com

[Tomasz Sowinski]

Eddie Velasquez wrote: Not Visual Studio. At least version 6.0 What's the importance of this? :-D Eddie Velasquez wrote: More exageration. Just a little bit :) Anyway, we're not going to agree. Let's finish this discussion. Tomasz Sowinski -- http://www.shooltz.com

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

[Eddie Velasquez]

Tomasz Sowinski wrote: What's the importance of this? Well, a lot of developers use it as it's main compiler? And the some big chunks of the standard aren't correctly handled by VC6 (and VC7). And that you implied (or so I interpreted) that because standard C++ uses exceptions all over the place then everybody is using exceptions unknowingly, so the exception overhead has already been payed for. And I said that VC6 doesn't conform very well so the exception overhead isn't automatically included. Tomasz Sowinski wrote: Anyway, we're not going to agree. Let's finish this discussion. That's ok with me.

---

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

[Tomasz Sowinski]

Eddie Velasquez wrote: And I said that VC6 doesn't conform very well so the exception overhead isn't automatically included It's included by default. Projects you create with wizard have exception handling turned on. MFC uses exceptions. Built-in COM support uses exceptions... Tomasz Sowinski -- http://www.shooltz.com

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

[Tomasz Sowinski]

Ok, ok, you've got me. But rules are made to break them, right? :-D Tomasz Sowinski -- http://www.shooltz.com

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

[Hans Dietrich]

Basically, what you want to do is call bunch of functions one after the other, but stop calling them once you get error. Here is code that will do that: BOOL rc = TRUE; if (rc) rc = rc && call1(); if (rc) rc = rc && call2(); if (rc) rc = rc && call3(); ... if (!rc) { // error handling code } else { // continue processing } You can use for any kind of sequential processing of functions, testing flags, etc. Best wishes, Hans

[Brit]

Then why not this?

if(!call1())
{
// cleanup
return;
}
if(!call2())
{
// cleanup
return;
}
if(!call3())
{
// cleanup
return;
}

Or:

if(!call1())
{
cleanup1();
return;
}
if(!call2())
{
cleanup2();
cleanup1();
return;
}
if(!call3())
{
cleanup3();
cleanup2();
cleanup1();
return;
}

[Alexandru Savescu]

:cool: Best regards, Alexandru Savescu

[Tomasz Sowinski]

You can remove && from expressions and use rc = callN() only. After all, this is executed only if rc is true - you're testing this condition few cycles before rc = rc && callN(). Tomasz Sowinski -- http://www.shooltz.com

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

[Christian Graus]

Jason Henderson wrote: Is Stroustrup trying to say it should only be used as a return mechanism if it isn't used in error handling? He's saying it's a valid way to control program flow, although it will most often be used to catch errors. He's suggesting that we not limit our thinking to error handling, because it can be used in other ways as well, which really are up to us as developers. Christian I am completely intolerant of stupidity. Stupidity is, of course, anything that doesn't conform to my way of thinking. - Jamie Hale - 29/05/2002

[Christian Graus]

Eddie Velasquez wrote: 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. Most arguments people put forth for the use of goto are better controlled with try/catch, of the type where multiple points in the code can branch to the same block at the bottom. Christian I am completely intolerant of stupidity. Stupidity is, of course, anything that doesn't conform to my way of thinking. - Jamie Hale - 29/05/2002

[Jonathan Gilligan]

This kind of thing does indeed get ugly, but there's more to solving it than indentation. It's hard to keep straight how deep you are into the nested if statements. Better to break out and write something like this:

bool ok(true);

ok = call1();
if (ok)
ok = call2();
if (ok)
ok = call3();
...

The bool variable doesn't hurt performance noticeably (the compiler will optimize it out anyway, when you compile for release), and it makes the whole thing much more readable.

[Nish Nishant]

Nice and simple solution. Thanks :-) Nish

---

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