Jobs at CodeProject?
-
Stooopid (and new) me.. sorry, I got the link.. thanx and disregard my "suggestion".
goto jobs;(don't use goto) Sonork ID: 0.2
Migs wrote: (don't use goto) Hey I notice you use "goto" migs, Could you write an artice explainig how it is effectivly used, I have always been interested. The emphasis on effectivly used I have never had it really well explained to me. Thanks! Regardz Colin J Davies
Sonork ID 100.9197:Colin
-
Stooopid (and new) me.. sorry, I got the link.. thanx and disregard my "suggestion".
goto jobs;(don't use goto) Sonork ID: 0.2
Hey Migs, I just re-read my post - it sounds a little obtuse. Sorry, no ill feelings intended. Welcome to CP. - Jon Jon Sagara "Ninety percent of baseball is mental, the other half is physical." -- Yogi Bera
-
Migs wrote: (don't use goto) Hey I notice you use "goto" migs, Could you write an artice explainig how it is effectivly used, I have always been interested. The emphasis on effectivly used I have never had it really well explained to me. Thanks! Regardz Colin J Davies
Sonork ID 100.9197:Colin
Colin:
The OOP extremists say: goto is NEVER to be used, it is as sinfull as cutting your pasta with a knife: It will make your code less understandable.
So, strictly speaking, there is NO way of using goto "efficiently".
In practice, I try to respect the NON use of goto as much as possible, but when I reach a situation where avoiding the goto statement makes me either:
a) Write a more complex code. c) Write a more inneficient code
I use it and shut my ears to purists ripping their cloths.
A clear example is: if a structure "PTR" is null or its "MEMBER" is 0, we do "B", else we do "A":
If CANNOT be written as:if(ptr!=NULL && ptr->member != 0) { // do stuff A } else { // do stuff B }Because the C/C++ compiler defs state CLEARLY that the compiler can choose the resolution order it thinks best. (testing ptr->member when ptr == NULL would kill our app).. so, we must write it this way:
if(ptr!=NULL) { if(ptr->member!=0) { // do stuff A } else { // do stuff B } } else { // do stuff B }See? unless I use GOTO, I'll have to write "stuff B" twice (larger code) or make stuff "B" a call to a function (slower code).
This could be re-written in a "holy" way like this:
for( ; ; ) { if(ptr != NULL ) { if( ptr->member!=0 ) { // do stuff A break; } } // do stuff B break; }This way, I've avoided the use of goto.. but is this code REALLY more understandable? break is very much a goto without a label.My rule of thumb:
a) Use goto ONLY when there's no other choice.(*1) b) try to fit the goto and its matching label in one screen c) Use goto ONLY when there's no other choice.(*1) d) NEVER cross-over 2 or more goto labels (at a given point, there should only be one goto "active"). e) Use goto ONLY when there's no other choice.(*1) f) Don't "goto" backwards: You probably could've written that better. (*1) Avoiding the use would make code fatter or slower in a meaningfull way. Sonork ID: 0.2 -
Colin:
The OOP extremists say: goto is NEVER to be used, it is as sinfull as cutting your pasta with a knife: It will make your code less understandable.
So, strictly speaking, there is NO way of using goto "efficiently".
In practice, I try to respect the NON use of goto as much as possible, but when I reach a situation where avoiding the goto statement makes me either:
a) Write a more complex code. c) Write a more inneficient code
I use it and shut my ears to purists ripping their cloths.
A clear example is: if a structure "PTR" is null or its "MEMBER" is 0, we do "B", else we do "A":
If CANNOT be written as:if(ptr!=NULL && ptr->member != 0) { // do stuff A } else { // do stuff B }Because the C/C++ compiler defs state CLEARLY that the compiler can choose the resolution order it thinks best. (testing ptr->member when ptr == NULL would kill our app).. so, we must write it this way:
if(ptr!=NULL) { if(ptr->member!=0) { // do stuff A } else { // do stuff B } } else { // do stuff B }See? unless I use GOTO, I'll have to write "stuff B" twice (larger code) or make stuff "B" a call to a function (slower code).
This could be re-written in a "holy" way like this:
for( ; ; ) { if(ptr != NULL ) { if( ptr->member!=0 ) { // do stuff A break; } } // do stuff B break; }This way, I've avoided the use of goto.. but is this code REALLY more understandable? break is very much a goto without a label.My rule of thumb:
a) Use goto ONLY when there's no other choice.(*1) b) try to fit the goto and its matching label in one screen c) Use goto ONLY when there's no other choice.(*1) d) NEVER cross-over 2 or more goto labels (at a given point, there should only be one goto "active"). e) Use goto ONLY when there's no other choice.(*1) f) Don't "goto" backwards: You probably could've written that better. (*1) Avoiding the use would make code fatter or slower in a meaningfull way. Sonork ID: 0.2Ok I have saved this and as I wade my way through your immense code I'll refer back to it. I just an unacustommed to seeing goto s at all and so I have to think, which is hard for me as I get older Migs, Hey put a coffe on! Regardz Colin J Davies
Sonork ID 100.9197:Colin
I live in Bob's HungOut now
-
Colin:
The OOP extremists say: goto is NEVER to be used, it is as sinfull as cutting your pasta with a knife: It will make your code less understandable.
So, strictly speaking, there is NO way of using goto "efficiently".
In practice, I try to respect the NON use of goto as much as possible, but when I reach a situation where avoiding the goto statement makes me either:
a) Write a more complex code. c) Write a more inneficient code
I use it and shut my ears to purists ripping their cloths.
A clear example is: if a structure "PTR" is null or its "MEMBER" is 0, we do "B", else we do "A":
If CANNOT be written as:if(ptr!=NULL && ptr->member != 0) { // do stuff A } else { // do stuff B }Because the C/C++ compiler defs state CLEARLY that the compiler can choose the resolution order it thinks best. (testing ptr->member when ptr == NULL would kill our app).. so, we must write it this way:
if(ptr!=NULL) { if(ptr->member!=0) { // do stuff A } else { // do stuff B } } else { // do stuff B }See? unless I use GOTO, I'll have to write "stuff B" twice (larger code) or make stuff "B" a call to a function (slower code).
This could be re-written in a "holy" way like this:
for( ; ; ) { if(ptr != NULL ) { if( ptr->member!=0 ) { // do stuff A break; } } // do stuff B break; }This way, I've avoided the use of goto.. but is this code REALLY more understandable? break is very much a goto without a label.My rule of thumb:
a) Use goto ONLY when there's no other choice.(*1) b) try to fit the goto and its matching label in one screen c) Use goto ONLY when there's no other choice.(*1) d) NEVER cross-over 2 or more goto labels (at a given point, there should only be one goto "active"). e) Use goto ONLY when there's no other choice.(*1) f) Don't "goto" backwards: You probably could've written that better. (*1) Avoiding the use would make code fatter or slower in a meaningfull way. Sonork ID: 0.2You CAN write
if (ptr != 0 && ptr->member != 0) { // do stuff A } else { // do stuff B }
C/C++ uses short circuit evaluation of boolean expressions, e.g. it is guaranteed that the first expression (ptr != 0) is evaluated first and if it is not true the second is not evaluated at all. Just take a look at the MSDN entry for the && operator. (One reason less for the goto statement :-D) regards Oliver
-
Stooopid (and new) me.. sorry, I got the link.. thanx and disregard my "suggestion".
goto jobs;(don't use goto) Sonork ID: 0.2
not so stupid it (cp-jobs) is not frequently updated i think many peope use another sites for sw job searches what about jobs-changed link into per-week cp news mail? maybe it will start to be more living t!
-
You CAN write
if (ptr != 0 && ptr->member != 0) { // do stuff A } else { // do stuff B }
C/C++ uses short circuit evaluation of boolean expressions, e.g. it is guaranteed that the first expression (ptr != 0) is evaluated first and if it is not true the second is not evaluated at all. Just take a look at the MSDN entry for the && operator. (One reason less for the goto statement :-D) regards Oliver
Thanks! Every time I see a goto, I see someone that has a wrong concept about C++ (or any other modern language). Every improvement is made to modern languages with (at least) structured programming in mind, and some languages even don't have goto's anymore. PS: "OOP extremists" appeared one or two decades after goto's were banished. People should see "structured programming" before studying OOP. Crivo Automated Credit Assessment
-
You CAN write
if (ptr != 0 && ptr->member != 0) { // do stuff A } else { // do stuff B }
C/C++ uses short circuit evaluation of boolean expressions, e.g. it is guaranteed that the first expression (ptr != 0) is evaluated first and if it is not true the second is not evaluated at all. Just take a look at the MSDN entry for the && operator. (One reason less for the goto statement :-D) regards Oliver
Oliver Anhuth wrote: C/C++ uses short circuit evaluation of boolean expressions I'd always wondered about that thanks for putting me straight. Whist I ahven't seen that documented, I naturally assumed it was logical, and put the fastest expression first etc. Yeah I just have never needed a goto in C++, and never missed it. Although I admit to using break; in switch statements, But I think that is acceptable. Although I never have had a use to use it elsewhere. I think the goto style of Migs must have inheritted from another language. Its not a real big issue for me but when I look at goto code I seem to have to think differently. But then some C++ coders apparently don't use pointers and that is another issue entirely. Regardz Colin J Davies
Sonork ID 100.9197:Colin
I live in Bob's HungOut now
-
You CAN write
if (ptr != 0 && ptr->member != 0) { // do stuff A } else { // do stuff B }
C/C++ uses short circuit evaluation of boolean expressions, e.g. it is guaranteed that the first expression (ptr != 0) is evaluated first and if it is not true the second is not evaluated at all. Just take a look at the MSDN entry for the && operator. (One reason less for the goto statement :-D) regards Oliver
Oliver,
You're assuming a compiler (VCC), which is fine (and undesrtandable in a MS-oriented forum) but, if you never indend your code to be compiled anywhere else, it is not alright
Are you sure BC does this? and what about GCC? how about Symantec's?
Where does the short circuit evaluation happen? in the compiler or in the optimizer? if in the second, which flag enables/disables this option? How about multithreaded applications? what if ptr is loaded into a register before entering the critical section but changed by another thread? See? too much relying on your compiler.. I don't buy that. I'm a C-programmer legacy which hates goto, but hates even more tool-dependency (reason for which I avoid as much as I can frameworks like MFC) VCC states it does that, ok.. but the C/C++ specs say that the compiler can evaluate expressions in ANY order the compiler thinks fit (as long as the result is the same)
Maybe my example doesn't apply well to VCC, but the idea still stands. Sonork ID: 0.2 -
Oliver,
You're assuming a compiler (VCC), which is fine (and undesrtandable in a MS-oriented forum) but, if you never indend your code to be compiled anywhere else, it is not alright
Are you sure BC does this? and what about GCC? how about Symantec's?
Where does the short circuit evaluation happen? in the compiler or in the optimizer? if in the second, which flag enables/disables this option? How about multithreaded applications? what if ptr is loaded into a register before entering the critical section but changed by another thread? See? too much relying on your compiler.. I don't buy that. I'm a C-programmer legacy which hates goto, but hates even more tool-dependency (reason for which I avoid as much as I can frameworks like MFC) VCC states it does that, ok.. but the C/C++ specs say that the compiler can evaluate expressions in ANY order the compiler thinks fit (as long as the result is the same)
Maybe my example doesn't apply well to VCC, but the idea still stands. Sonork ID: 0.2Hello Migs, I am a C relict too. I am doing cross platform development on Windows/Unix/VMS (besides MFC development for Windows). I developed with C for SunOS, HPUX, Linux, MSDOS, SINIX, Solaris, VMS, Win32 (the Petzold way). In each of these environments there were short circuit evaluation. It was even there in old K&R C. I am currently looking at my copy of Kernigan and Ritchie (the ANSI edition). It specifies short circuit evaluation for &&. So I am pretty confident that it is part of the ANSI C standard and each and every C/C++ compiler I might encounter will do it the same way. I remember missing this very badly with VAX Pascal when I was at university, because it was not in standard Pascal. Turbo Pascal had a switch to turn it on and Modula 2 included it from the start. regards Oliver
-
Hello Migs, I am a C relict too. I am doing cross platform development on Windows/Unix/VMS (besides MFC development for Windows). I developed with C for SunOS, HPUX, Linux, MSDOS, SINIX, Solaris, VMS, Win32 (the Petzold way). In each of these environments there were short circuit evaluation. It was even there in old K&R C. I am currently looking at my copy of Kernigan and Ritchie (the ANSI edition). It specifies short circuit evaluation for &&. So I am pretty confident that it is part of the ANSI C standard and each and every C/C++ compiler I might encounter will do it the same way. I remember missing this very badly with VAX Pascal when I was at university, because it was not in standard Pascal. Turbo Pascal had a switch to turn it on and Modula 2 included it from the start. regards Oliver
Oliver, I've checked up and down every resource I know and I've compiled several tests on VCC using multithreaded (to check the assembly output) and yes: Short Circuit and proper register re-loading are done everytime. So, you're right.. the short circuit would solve the
(ptr==NULL&&ptr->member!=0)issue. However, even after aknowledging that the example was a bad one, I must insist on the fact that even when goto can be avoided every time, sometimes avoiding it causes you to write less efficient code. Also consider that, at the very end, your assembly output is nothing but a huge set of "gotos" all over the place.. and the closer you get to the machine's language, the more efficient you potentialy can get.. (and yes: the more unreadable your code can also get) Thanks for having taken your time on replying to this.. I will now start relying more heavily (shiver) on short circuit evaluation. Sonork ID: 0.2 -
Oliver,
You're assuming a compiler (VCC), which is fine (and undesrtandable in a MS-oriented forum) but, if you never indend your code to be compiled anywhere else, it is not alright
Are you sure BC does this? and what about GCC? how about Symantec's?
Where does the short circuit evaluation happen? in the compiler or in the optimizer? if in the second, which flag enables/disables this option? How about multithreaded applications? what if ptr is loaded into a register before entering the critical section but changed by another thread? See? too much relying on your compiler.. I don't buy that. I'm a C-programmer legacy which hates goto, but hates even more tool-dependency (reason for which I avoid as much as I can frameworks like MFC) VCC states it does that, ok.. but the C/C++ specs say that the compiler can evaluate expressions in ANY order the compiler thinks fit (as long as the result is the same)
Maybe my example doesn't apply well to VCC, but the idea still stands. Sonork ID: 0.2All rise for a reading from the C standard. In section 6.3.13, we read: "Unlike the binary & operator, the && operator guarantees left-to-right evaluation; there is a sequence point after the evaluation of the first operand. If the first operand compares equal to 0, the second operand is not evaluated." You may be seated. (BTW: I'm not a language lawyer, but I play one at work.) There is similar wording for the || operator. Any compiler that wishes to call itself a C compiler must implement short-circuit evaluation for && and ||. Stroustroup's ARM has similar wording, though I'm not sure if short-circuit evaluation still applies to an overloaded operator&& or operator||. Getting back to the use of goto: personally, while I'm not manic about avoiding it, I also have never used one since I started using exceptions. (I used to use them a lot for jumping to appropriate clean-up code.) - Rich I don't know about ignorance, and I don't care about apathy, but I simply will NOT put with intolerance!