Platform SDK documentation
-
gotois only bad when used inappropriately - it makes it easy to write very unstructured code. Two things to consider: 1) Think about what abreakorcontinuestatement actually does 2) Look at the generated assembly language for any C/C++ code you write. You'll see a lot ofJMP,JNZand so on. What are those doing, if not agoto? In reality, you write a lot ofgotostatements, you just don't realise it.Graham Bradshaw wrote:
it makes it easy to write very unstructured code.
I agreed with that. And i would add illegible, unmanageable...
Graham Bradshaw wrote:
break or continue
break and continue (actually i don't use continue) don't make the code a mess. Someone who read the code can understand easily what it's going on. Write 4 or 5 gotos in any function and few people will understand it.
Graham Bradshaw wrote:
Look at the generated assembly language for any C/C++ code you write. You'll see a lot of JMP, JNZ and so on.
IMO, that's one of the reasons high level languages were designed. BTW, my original post was only to make a "funny comment", but i'm really impressed. I'm thinking about posting a thread asking how many people use gotos. Since i started to learn programming i've been told that gotos are something like a sin.
-
I've found this example (just look at SafeArrayGetElement)
STDMETHODIMP CEnumPoint::Next( ULONG celt, VARIANT FAR rgvar[], ULONG * pceltFetched) { /// ... omited for(i = 0; i < celt; ++i){ // Are we at the last element? if(m_iCurrent == m_celts){ hresult = S_FALSE; goto LDone; } ix = m_iCurrent++; // m_psa is a global variable that holds the safe array. hresult = SafeArrayGetElement(m_psa, &ix, &rgvar[i]); if(FAILED(hresult)) goto LError0; } hresult = NOERROR; LDone:; if (pceltFetched != NULL) *pceltFetched = i; return hresult; LError0:; for(i = 0; i < celt; ++i) VariantClear(&rgvar[i]); return hresult; }goto LError0; :omg: goto LDone; :wtf: i've been shaking some minutes but now i'm ok goto Work; :~In my current project I might have write, perhaps, 5 goto and 1 do {} while() It's hard sometimes, but I managed to get over it ... :laugh:
-
Graham Bradshaw wrote:
it makes it easy to write very unstructured code.
I agreed with that. And i would add illegible, unmanageable...
Graham Bradshaw wrote:
break or continue
break and continue (actually i don't use continue) don't make the code a mess. Someone who read the code can understand easily what it's going on. Write 4 or 5 gotos in any function and few people will understand it.
Graham Bradshaw wrote:
Look at the generated assembly language for any C/C++ code you write. You'll see a lot of JMP, JNZ and so on.
IMO, that's one of the reasons high level languages were designed. BTW, my original post was only to make a "funny comment", but i'm really impressed. I'm thinking about posting a thread asking how many people use gotos. Since i started to learn programming i've been told that gotos are something like a sin.
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
-
I've found this example (just look at SafeArrayGetElement)
STDMETHODIMP CEnumPoint::Next( ULONG celt, VARIANT FAR rgvar[], ULONG * pceltFetched) { /// ... omited for(i = 0; i < celt; ++i){ // Are we at the last element? if(m_iCurrent == m_celts){ hresult = S_FALSE; goto LDone; } ix = m_iCurrent++; // m_psa is a global variable that holds the safe array. hresult = SafeArrayGetElement(m_psa, &ix, &rgvar[i]); if(FAILED(hresult)) goto LError0; } hresult = NOERROR; LDone:; if (pceltFetched != NULL) *pceltFetched = i; return hresult; LError0:; for(i = 0; i < celt; ++i) VariantClear(&rgvar[i]); return hresult; }goto LError0; :omg: goto LDone; :wtf: i've been shaking some minutes but now i'm ok goto Work; :~Hey! Dont speak too bad about "goto"s. While you are coding, at some point you'll feel like, "Now how do I f*ck off from this block of code??:confused:". There it comes to the rescue like a spiderman :cool:.
--[V]--
-
gotois only bad when used inappropriately - it makes it easy to write very unstructured code. Two things to consider: 1) Think about what abreakorcontinuestatement actually does 2) Look at the generated assembly language for any C/C++ code you write. You'll see a lot ofJMP,JNZand so on. What are those doing, if not agoto? In reality, you write a lot ofgotostatements, you just don't realise it.Graham Bradshaw wrote:
- Look at the generated assembly language for any C/C++ code you write. You'll see a lot of JMP, JNZ and so on. What are those doing, if not a goto?
But the compiler does that for you :-). I never use continue or goto and break only in switch statements, but idd as with all things, if you use it in a good way it can't do any harm :-) Coulda, woulda, shoulda doesn't matter if you don't. :beer:
:jig: :jig: :jig: :jig: :jig: :jig: :jig: :jig: :jig: :jig: :jig: -
Hey! Dont speak too bad about "goto"s. While you are coding, at some point you'll feel like, "Now how do I f*ck off from this block of code??:confused:". There it comes to the rescue like a spiderman :cool:.
--[V]--
typically for() { for() { for() { if(condition) exit_all_for.... <= goto! ( except in java :cool: (which has labelled break)) } } }
-
Hey! Dont speak too bad about "goto"s. While you are coding, at some point you'll feel like, "Now how do I f*ck off from this block of code??:confused:". There it comes to the rescue like a spiderman :cool:.
--[V]--
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.
-
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
}