A question of indentation!

[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.

[Oliver Anhuth]

Hello Nish, in such cases I prefer the following indention style:

int result;

result = call1();
if (result)
{
result = call2();
}

if (result)
{
result = call3();
}

if (result)
{
result = call4();
}

and so on. This may take getting used to, but it keeps the indention level constant. regards Oliver

[Len Holgate]

Nish - Native CPian wrote: The problem is that each of these functions require something from the previous function. For example if fn_1 allocs something, then fn_2 uses that and allocs something else used by fn_3 and so on. On failure at any point I also have to call the respective deallocing PGP functions in reverse order That's the point. If you need to allocate a resource you do so in the constructor, you then use the resource, perhaps to allocate another resource, and release it in the destructor, hence you end up with code like:

CUsesPGP usesPGP(initStuff);

CPGPProvider provider("MyProvider");

CPGPKey key provider.GetKey("Blah");

CPGPData data(pData, length);

data.Encrypt(key);

The c++ class construction order makes sure that the resources are released correctly even if an exception is thrown. Methods throw exceptions so that the user cant ignore errors by default. The code is pretty much self documenting so you dont need huge comment blocks that get out of date. Oh, and it fixes your indentation problem... Len Holgate www.jetbyte.com The right code, right now.