Platform SDK documentation
-
VuNic wrote:
Now how do I f*ck off from this block of code??
return; return whatever; break; in some cases. (just when you are looking something within a loop) if i can't use one of the above sentences if because i did a bad work designing the code. Then, redesign and get a clearest code.
yeah, with "breaks" the control can only "fall down", and not where we'd like to point to. But in some conditions, very rarely I had to use "goto" may be once in the entire program. But I agree, when I use it, I feel bit guilty :-D
--[V]--
-
Gizzo wrote:
Since i started to learn programming i've been told that gotos are something like a sin.
Yeah, you get that from professors and people who have their heads in the clouds. Gotos have a practical purpose - you should use them in any place where you can't use a regular control or looping construct. It's useful when you've got a lot of common cleanup-and-exit code in a function, which otherwise you'd have to either repeat or set a cleanup flag. Single-exit functions (all functions are now single-entry) are allegedly desirable according to the purists, but in my opinion inevitably lead to a forest of braces and deeply nested code. In languages that support it, you could use try/catch to implement a cleanup block by throwing an exception at the point that the error is detected. However, a try/catch is almost always much more expensive than a goto. Dijkstra's original 'GOTO considered harmful' paper was written at a time where the predominant languages did not include good control and looping constructs. Now they do. Use the goto sparingly, only where necessary - but don't subvert the control and looping constructs just to avoid a goto. Stability. What an interesting concept. -- Chris Maunder
-
typically for() { for() { for() { if(condition) exit_all_for.... <= goto! ( except in java :cool: (which has labelled break)) } } }
Super Lloyd wrote:
labelled break
Is it?? so it's an implicit "goto" right??
--[V]--
-
Super Lloyd wrote:
labelled break
Is it?? so it's an implicit "goto" right??
--[V]--
it is. but "goto shy" people prefer it as it is "more structured"
-
Gizzo wrote:
Since i started to learn programming i've been told that gotos are something like a sin.
Yeah, you get that from professors and people who have their heads in the clouds. Gotos have a practical purpose - you should use them in any place where you can't use a regular control or looping construct. It's useful when you've got a lot of common cleanup-and-exit code in a function, which otherwise you'd have to either repeat or set a cleanup flag. Single-exit functions (all functions are now single-entry) are allegedly desirable according to the purists, but in my opinion inevitably lead to a forest of braces and deeply nested code. In languages that support it, you could use try/catch to implement a cleanup block by throwing an exception at the point that the error is detected. However, a try/catch is almost always much more expensive than a goto. Dijkstra's original 'GOTO considered harmful' paper was written at a time where the predominant languages did not include good control and looping constructs. Now they do. Use the goto sparingly, only where necessary - but don't subvert the control and looping constructs just to avoid a goto. Stability. What an interesting concept. -- Chris Maunder
Mike Dimmick wrote:
Single-exit functions (all functions are now single-entry) are allegedly desirable according to the purists, but in my opinion inevitably lead to a forest of braces and deeply nested code.
Can't agree with you more. While I admit the concept of a single exit is good, going to great lengths to do that, when a immediate return would be more appropriate, is very bad IMO. Also, I find that single exit methods make me hold a lot more context in my head than those that return immediately. Regards Senthil _____________________________ My Blog | My Articles | WinMacro
-
Mike Dimmick wrote:
Single-exit functions (all functions are now single-entry) are allegedly desirable according to the purists, but in my opinion inevitably lead to a forest of braces and deeply nested code.
Can't agree with you more. While I admit the concept of a single exit is good, going to great lengths to do that, when a immediate return would be more appropriate, is very bad IMO. Also, I find that single exit methods make me hold a lot more context in my head than those that return immediately. Regards Senthil _____________________________ My Blog | My Articles | WinMacro
-
yeah, with "breaks" the control can only "fall down", and not where we'd like to point to. But in some conditions, very rarely I had to use "goto" may be once in the entire program. But I agree, when I use it, I feel bit guilty :-D
--[V]--
-
goto gives you freedom. When freedom is misused, you get chaos. Maybe, MS programmers are very adventerous. . . .resulting in all their bug troubles.
Thomas George wrote:
MS programmers are very adventerous. . .
Not only MS programmers, Linux ones also. As below: linux/fs/pipe.c[^] :-D [Edit] Apple ones also, as: Calling_AppleScript.c[^] :laugh::laugh::laugh: [/Edit]
Maxwell Chen -- modified at 6:39 Friday 5th May, 2006
-
Again, the answer is maintenance. I don't agree with rigid rules, but, if you should consider whether your code will be understood by people maintaining it. If you have numerous exit points in a function, then maybe the function is doing too much :).
Well, which piece of code do you think is more maintainable. 1.
HRESULT DoSomething(int param1, int param2)
{
if (IsInvalidParam1(param1))
return E_INVALIDPARAM1;
if (IsInvalidParam2(param2))
return E_INVALIDPARAM2;
if (param1 != param2)
return E_INVALIDARGS;
//Do Actual stuff
return S_OK;
}HRESULT DoSomething(int param1, int param2)
{
HRESULT ret = S_OK;
if (IsInvalidParam1(param1))
{
ret = E_INVALIDPARAM1;
}
else if (IsInvalidParam2(param2))
{
ret = E_INVALIDPARAM2;
}
else
{
if (param1 != param2)
ret = E_INVALIDARGS;
else
{
//Do Actual stuff
}
}
return ret;
}Regards Senthil _____________________________ My Blog | My Articles | WinMacro
-
Well, which piece of code do you think is more maintainable. 1.
HRESULT DoSomething(int param1, int param2)
{
if (IsInvalidParam1(param1))
return E_INVALIDPARAM1;
if (IsInvalidParam2(param2))
return E_INVALIDPARAM2;
if (param1 != param2)
return E_INVALIDARGS;
//Do Actual stuff
return S_OK;
}HRESULT DoSomething(int param1, int param2)
{
HRESULT ret = S_OK;
if (IsInvalidParam1(param1))
{
ret = E_INVALIDPARAM1;
}
else if (IsInvalidParam2(param2))
{
ret = E_INVALIDPARAM2;
}
else
{
if (param1 != param2)
ret = E_INVALIDARGS;
else
{
//Do Actual stuff
}
}
return ret;
}Regards Senthil _____________________________ My Blog | My Articles | WinMacro
S. Senthil Kumar wrote:
which piece of code do you think is more maintainable
The first one.
Maxwell Chen
-
Well, which piece of code do you think is more maintainable. 1.
HRESULT DoSomething(int param1, int param2)
{
if (IsInvalidParam1(param1))
return E_INVALIDPARAM1;
if (IsInvalidParam2(param2))
return E_INVALIDPARAM2;
if (param1 != param2)
return E_INVALIDARGS;
//Do Actual stuff
return S_OK;
}HRESULT DoSomething(int param1, int param2)
{
HRESULT ret = S_OK;
if (IsInvalidParam1(param1))
{
ret = E_INVALIDPARAM1;
}
else if (IsInvalidParam2(param2))
{
ret = E_INVALIDPARAM2;
}
else
{
if (param1 != param2)
ret = E_INVALIDARGS;
else
{
//Do Actual stuff
}
}
return ret;
}Regards Senthil _____________________________ My Blog | My Articles | WinMacro
That is not a suitable piece of code to illustrate the perils of multiple returns. All the returns are orderly and on the same nesting level, and gets done before the intended work of the function begins. So, (1) is an obvious choice. I already stated that I am not an absolutist, and does not favour any rigid rules. What if there are returns littered in the "Do Actual stuff" also. When you have returns sprinked in a piece of code at different nesting levels, it can be quite hard to understand. Thomas
-
That is not a suitable piece of code to illustrate the perils of multiple returns. All the returns are orderly and on the same nesting level, and gets done before the intended work of the function begins. So, (1) is an obvious choice. I already stated that I am not an absolutist, and does not favour any rigid rules. What if there are returns littered in the "Do Actual stuff" also. When you have returns sprinked in a piece of code at different nesting levels, it can be quite hard to understand. Thomas
Thomas George wrote:
I already stated that I am not an absolutist, and does not favour any rigid rules.
Me too, I admit that returns at different nesting levels can be hard to understand, but I personally have been forced to use (2) instead of (1), simply because (1) had multiple points of exit. I guess we both agree more than we disagree then :) Regards Senthil _____________________________ My Blog | My Articles | WinMacro
-
Probably i'm going to ask the stupid question of the thread, but... What has to do try/catch with goto? Can the goto statement catch an exception?
instead of:
for (int i=0;i<1000;i++)
{
if (i==500) goto end;
}
end;you would do this:
try
{
for (int i=0;i<1000;i++)
{
if (i==500) throw something;
}
}
catch (something e)
{
// el yay
} -
instead of:
for (int i=0;i<1000;i++)
{
if (i==500) goto end;
}
end;you would do this:
try
{
for (int i=0;i<1000;i++)
{
if (i==500) throw something;
}
}
catch (something e)
{
// el yay
} -
And why not... for(int i=0; i<1000; i++) { if(i==500) break; } -- modified at 7:50 Friday 5th May, 2006 I'd like to add that an exception should be used for exceptional cases that could happend in the execution, but not for flow control.
Gizzo wrote:
And why not
because you didn't ask about break and goto, you asked about try/catch and goto. Cleek | Image Toolkits | Thumbnail maker
-
Gizzo wrote:
And why not
because you didn't ask about break and goto, you asked about try/catch and goto. Cleek | Image Toolkits | Thumbnail maker
-
And why not... for(int i=0; i<1000; i++) { if(i==500) break; } -- modified at 7:50 Friday 5th May, 2006 I'd like to add that an exception should be used for exceptional cases that could happend in the execution, but not for flow control.
Because break; doesn't work if you have nested loops. In my opinion, using goto with a well-named label is better than setting a flag (often named "ok" or "abort") to leave nested loops.
-
ok, ok, you are right, but what i wanted to known is why people is comparing try/catch with goto, when they are different statements which should be used in diferent cases.
people have been taught that goto is evil. try/throw/catch can do what goto does (which is sometimes exactly what a function needs). and since try/throw/catch is not a goto, you aren't breaking the "NEVER YOU GOTOs" rule when you do it. Cleek | Image Toolkits | Thumbnail maker
-
Well, which piece of code do you think is more maintainable. 1.
HRESULT DoSomething(int param1, int param2)
{
if (IsInvalidParam1(param1))
return E_INVALIDPARAM1;
if (IsInvalidParam2(param2))
return E_INVALIDPARAM2;
if (param1 != param2)
return E_INVALIDARGS;
//Do Actual stuff
return S_OK;
}HRESULT DoSomething(int param1, int param2)
{
HRESULT ret = S_OK;
if (IsInvalidParam1(param1))
{
ret = E_INVALIDPARAM1;
}
else if (IsInvalidParam2(param2))
{
ret = E_INVALIDPARAM2;
}
else
{
if (param1 != param2)
ret = E_INVALIDARGS;
else
{
//Do Actual stuff
}
}
return ret;
}Regards Senthil _____________________________ My Blog | My Articles | WinMacro
-
Again, the answer is maintenance. I don't agree with rigid rules, but, if you should consider whether your code will be understood by people maintaining it. If you have numerous exit points in a function, then maybe the function is doing too much :).
Thomas George wrote:
If you have numerous exit points in a function, then maybe the function is doing too much
Possibly, but not always. Take for example a function that is verifying a user input against a set of rules. It makes sense to test one rule and return immediately if it fails, then test the next and return immediate if it fails etc.
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"