Goto, Break and Continue
category: offtopic [glöplog]
@svo: That!
Even if I haven't use goto for a long and rarely need it, it became kinda of a dogma where it's a sin to even use one and programmers would reactively screetch seeing one, even in the proper cases. While, there are other C++ things that are too confusing to me, for the same reasons that people were critical on goto (recently, we were using boost signals at work, and I was like wtf, where am I supposed to know where the signal comes and what it calls without search all over the source code, lost the flow when debugging, but it's ok because it's a cool new and useful at some cases thing).
Even if I haven't use goto for a long and rarely need it, it became kinda of a dogma where it's a sin to even use one and programmers would reactively screetch seeing one, even in the proper cases. While, there are other C++ things that are too confusing to me, for the same reasons that people were critical on goto (recently, we were using boost signals at work, and I was like wtf, where am I supposed to know where the signal comes and what it calls without search all over the source code, lost the flow when debugging, but it's ok because it's a cool new and useful at some cases thing).
Yeah, signals are way worse than just a simple goto. But it’s boost so of course it’s cool and fancy to use.
I recommend COMEFROM
with multiple COMFROM it automagically creates threads, awesome!
Here's a goto avoidance pattern I saw in real code this week:
Code:
for (int i=0;i<1;i++) {
int err = try_something();
if (err) break;
err = try_something_else();
if (err) break;
/* and so on */
}
cleanup();
More like an antipattern to me. "if (err) goto cleanup; normal(); return; cleanup: cleanup(stuff); }" is clearer to me.
Also, nothing new has been said for the last two pages. Just go make a demo.
Oh man...
The main Disjktra's point was not about readability, but about proving code correctness.
But what we are even talking about... average "code pusher" today is creating more bugs than features and everyone is actually happy about it (because it is nicely inflating the cost of making software).
The main Disjktra's point was not about readability, but about proving code correctness.
But what we are even talking about... average "code pusher" today is creating more bugs than features and everyone is actually happy about it (because it is nicely inflating the cost of making software).
Quote:
Can I have your opinions on the use of goto, break and continue statements in code?
I would really like to learn the reason you are asking this.
When I started learning how to code I used to use goto A LOT. Nowadays it seems to me more of a deprecated way to do stuff and I mostly use it when there is no other way of doing sth differently, like for example in .bat files. The jumping commands for me is system that is old and is included in most languages for either the case of someone starting to learn how to code or when there is no other way for the coder to do sth.
Quote:
for (int i=0;i<1;i++) {
Also saw this more compact as for (;;) of course, but at some places as while(0,0) - not sure what the second 0 is, something about compiler warnings. Bizarre.
No idea why (0,0) would be less warning-prone than (0), but it sure looks cool.
https://stackoverflow.com/questions/1853723/in-c-macros-should-one-prefer-do-while0-0-over-do-while0
I still don't understand what's the second 0. Never seen this syntax before. As one puts it in the comments, maybe your code needs more owls :)
I still don't understand what's the second 0. Never seen this syntax before. As one puts it in the comments, maybe your code needs more owls :)
It's what called the built-in comma operator. In this form, the first expression (the first 0) is evaluated, and its result is discarded. Then the second expression is evaluated (the second 0) and it's result is returned. As said in the comments, in the case of while(0,0) the only reason is to have it shut up that MVSC warning.
Quote:
Here's a goto avoidance pattern I saw in real code this week:
Code:for (int i=0;i<1;i++) { int err = try_something(); if (err) break; err = try_something_else(); if (err) break; /* and so on */ } cleanup();
Exceptions were not available? That code above is not exception safe (and what Stroustroup calls "a rat's nest of tests" - which I 100% agree with).
http://www.stroustrup.com/bs_faq2.html#exceptions-why
salinga: not everyone is using c++, and even if they are, not everyone is willing to pay the resulting ~5% performance hit.
I've always thought that jump instructions are evil. Memory loads and stores are evil too, let alone register manipulations. Awful side effects, the previous value is usually almost completely destroyed. Even NOP is unsafe because it moves the instruction pointer!
Quote:
the resulting ~5% performance hit.
http://nibblestew.blogspot.com/2017/01/measuring-execution-performance-of-c.html
C++ coders can't even make clickable links!
@utz: Thanks!
Well, hopefully in a few decades std::optional will have arrived in mainstream production and we can finally be done with error codes vs exceptions ducks
@Optimus, some more info on the comma operator:
https://www.fluentcpp.com/2018/07/31/how-to-get-along-with-the-comma-operator/
@Optimus, some more info on the comma operator:
https://www.fluentcpp.com/2018/07/31/how-to-get-along-with-the-comma-operator/
The problem is a lot of programmer dont know the difference between an error and a status and mix them together. You dont use status code values to transmit an error info and you dont use exceptions to transmit a status info. Also exceptions prevent redundant code; checking a result code for an error per "if" is code executed 100% of the time for 0.0001% of the chance that an error happens. That alone gives you a clue. Plus that exception handling breaks out the error handling code out of the routine, where it does not belong. Plus that it forces a programmer to always think about how a resource (memory, handle, transaction, connection) at initialization is always freed (see RAII), which causes always stable running code if an error happens or not.
Not really a goto, not even a goto-avoidance trick, but it actually puzzled me for a minute this morning (grossly simplified in this snippet):
It's lovely that gcc, g++ and clang all produce slightly different errors here. g++4.3 being the most helpful, clang being absurdly confusing.
Code:
int dudu(int k)
{
switch (k) {
case 0:
int m = 3;
return m * k;
case 1: //can you guess compiler error without compiling?
return k;
}
}
It's lovely that gcc, g++ and clang all produce slightly different errors here. g++4.3 being the most helpful, clang being absurdly confusing.
you sure it produces errors? not warnings?!
seems like a normal fallthrough to me, so the first return would be used in case of k=0 !
oh, wait, there´s no return at all in case k>1, so...
"function doesn´t always return a value"...sth like that of an error-msg?
seems like a normal fallthrough to me, so the first return would be used in case of k=0 !
oh, wait, there´s no return at all in case k>1, so...
"function doesn´t always return a value"...sth like that of an error-msg?
Basically this thread is not about if a goto is accepted amongst coders (because of readability), but about what yzi said.
If you jump (goto), the predictability is gone, so the cache has to rebuild completely and so on...this is maybe how the thread-starter came up with the Q i guess.
Having said this, the breaks in a switch i mentioned earlier should be very predictable still, or?! so this shouldn´t be a big problem at all. same with return and even continue.
If you jump (goto), the predictability is gone, so the cache has to rebuild completely and so on...this is maybe how the thread-starter came up with the Q i guess.
Having said this, the breaks in a switch i mentioned earlier should be very predictable still, or?! so this shouldn´t be a big problem at all. same with return and even continue.
Quote:
http://nibblestew.blogspot.com/2017/01/measuring-execution-performance-of-c.html
the thing is, this assumes that you actually go down the rabbit hole of nested error code handling/passthrough with nesting level >= 1 or 2. Which I (and many others) don't. If some critical DirectX call fails e.g., something is seriously wrong and I just assert/abort.