## Re: if/else-if blocks in Obj-C

 Re: if/else-if blocks in Obj-C From: Dan Christiansen - 2003-03-29 14:31:32 ```On Saturday, March 29, 2003, at 03:07 PM, Liam mac Lynne wrote: > On Friday, March 28, 2003, at 07:29 PM, Reid Ellis wrote: > >> I didn't see anyone else mention this, so I thought I should.. > > Thanks, that's actually the code syntax I want to avoid b/c it's a bit=20= > obfuscated. > Sl=E1n, > Liam Honestly, I don't see how that can be obfuscated. I believe it's the=20 standard behavior for virtually all programing languages. If you wish=20 to clarify that c isn't 1, you could do it in a comment. > if (c=3D=3D1) { > ... > } else if (c!=3D0) { > /* c !=3D 1 */ > }= ```

 Re: if/else-if blocks in Obj-C From: Liam mac Lynne - 2003-03-26 05:24:11 ```-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, March 25, 2003, at 10:30 PM, Nick Kocharhook wrote:=0D =0D > My algorithms teacher would have a heart attack if she saw this code.=0D= > :-) Alan already answered your question, but really there should never=0D= > be a situation wherein two blocks of an if statement overlap. Perhaps=0D= > that if block should be re-thought?=0D =0D If only I'd stuck w/ the major instead of just a CS minor, I'd've had =0D= an algorithms teacher to have me pointed towards a cleaner road. I wish =0D= I knew who thought of it first; I'm trying to bug-fix around it, and =0D short of doing this:=0D =0D c=3D1 //for argument's sake=0D if (c=3D=3D1) {=0D //some stuff=0D } else if (c!=3D1&&c!=3D0) {=0D //diff stuff=0D }=0D =0D ... which strikes me as archetypically inelegant, but basically =0D effective. Similarly "ugly" to my eyes is nesting the first if block as =0D= a special case within the second - it further obfuscates code, though =0D= the structure then in some manner reflects the possible values for c - =0D= though I'm not sure the inferred structure in those values was =0D intended. What I really want to know is why the c=3D=3D0 case is being = left =0D as a clean-up case outside all if-blocks; the if-block clearly ignores =0D= a part of the range of c. Perhaps I can be speculative yet again & =0D wonder if that's part of the source of this bug?=0D Sl=E1n,=0D Liam=0D =0D - -----BEGIN GEEK CODE BLOCK-----=0D http://www.geekcode.com/=0D Version: 3.12=0D GS d-- s+:-- a-- C++ U*++ P+ L+ E W++ N o? K- w---=0D O- M++ V- PS+ PE Y+ PGP++ t+ 5+ X R++ tv-- b++ DI+ D----=0D G e++ h--- r+++ y?=0D - ------END GEEK CODE BLOCK------=0D -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (Darwin) iD8DBQE+gTlzttNNRfIgqyIRAlu4AJ96wKu6eWN/BAk/8xHnvXvw777nOwCfSqSd GRDdCQ9PA3HEKetzwYlQl1A=3D =3DcFEf -----END PGP SIGNATURE----- ```
 Re: if/else-if blocks in Obj-C From: Liam mac Lynne - 2003-03-29 14:07:54 ```-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, March 28, 2003, at 07:29 PM, Reid Ellis wrote:=0D =0D > I didn't see anyone else mention this, so I thought I should..=0D =0D Thanks, that's actually the code syntax I want to avoid b/c it's a bit =0D= obfuscated.=0D Sl=E1n,=0D Liam=0D =0D - -----BEGIN GEEK CODE BLOCK-----=0D http://www.geekcode.com/=0D Version: 3.12=0D GS d-- s+:-- a-- C++ U*++ P+ L+ E W++ N o? K- w---=0D O- M++ V- PS+ PE Y+ PGP++ t+ 5+ X R++ tv-- b++ DI+ D----=0D G e++ h--- r+++ y?=0D - ------END GEEK CODE BLOCK------=0D -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (Darwin) iD8DBQE+haiyttNNRfIgqyIRAh0HAJ919kvWnPQvm6UJ/rlEhdZJteRFHgCeLUSm T70VNmeyCvTvJEe/P/noyy8=3D =3DMSvM -----END PGP SIGNATURE----- ```
 Re: if/else-if blocks in Obj-C From: Dan Christiansen - 2003-03-29 14:31:32 ```On Saturday, March 29, 2003, at 03:07 PM, Liam mac Lynne wrote: > On Friday, March 28, 2003, at 07:29 PM, Reid Ellis wrote: > >> I didn't see anyone else mention this, so I thought I should.. > > Thanks, that's actually the code syntax I want to avoid b/c it's a bit=20= > obfuscated. > Sl=E1n, > Liam Honestly, I don't see how that can be obfuscated. I believe it's the=20 standard behavior for virtually all programing languages. If you wish=20 to clarify that c isn't 1, you could do it in a comment. > if (c=3D=3D1) { > ... > } else if (c!=3D0) { > /* c !=3D 1 */ > }= ```
 Re: if/else-if blocks in Obj-C From: Liam mac Lynne - 2003-03-29 15:53:23 ```-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, March 29, 2003, at 09:31 AM, Dan Christiansen wrote:=0D =0D > Honestly, I don't see how that can be obfuscated. I believe it's the =0D= > standard behavior for virtually all programing languages. If you wish =0D= > to clarify that c isn't 1, you could do it in a comment.=0D =0D Compare to the behavior of a "switch" structure in C, where if you =0D don't have a "break" statement at the end of a "case", the instructions =0D= for the next case will also be executed. One can analogize/re-represent =0D= that as the "else" behaving as a "break" where the "if"s are the =0D "case"s. Thus my confusion - I wasn't sure that the "else" really *did* =0D= behave as a "break" does. And I suspect I wouldn't have been confused =0D= if the comment you suggest had been present; it's not.=0D Also, I usually code in Fortran (well, F77) and it does some =0D mind-numbingly yucky things with loops and conditionals, and I don't =0D even always remember them.=0D In any case, as Nick pointed out, we only get 3 inputs values for =0D returnCode, and so in some sense using the c=3D=3D1, c!=3D0 is a bad way = of =0D doing things to start with; we then don't explicitly handle the third =0D= case (c=3D=3D0), and certain things we do inside the if-blocks cause a =0D= crash in this trailing code.=0D =0D Which reminds me... a power outage killed my Accounts/FireConfiguration =0D= .plists, and certain folks who've been helping me test GPG things on =0D ICQ and Jabber, well, I've gone & lost your SNs. (Doh!) Definitely need =0D= to replace that UPS battery...=0D Sl=E1n,=0D Liam=0D =0D - -----BEGIN GEEK CODE BLOCK-----=0D http://www.geekcode.com/=0D Version: 3.12=0D GS d-- s+:-- a-- C++ U*++ P+ L+ E W++ N o? K- w---=0D O- M++ V- PS+ PE Y+ PGP++ t+ 5+ X R++ tv-- b++ DI+ D----=0D G e++ h--- r+++ y?=0D - ------END GEEK CODE BLOCK------=0D -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (Darwin) iD8DBQE+hcEcttNNRfIgqyIRAjseAJ9NY4hnGMP5S/2cxLTbl6RlOVM3qQCfUYo2 eibfx6+mskS+FRz4MsglQZk=3D =3Dt37v -----END PGP SIGNATURE----- ```
 Re: if/else-if blocks in Obj-C From: Nick Kocharhook - 2003-03-26 08:59:40 ```On Wed, Mar 26, 2003 at 12:23:58AM -0500, Liam mac Lynne proclaimed: > I'm trying to bug-fix around it, and short of doing this: > > c=1 //for argument's sake > if (c==1) { > //some stuff > } else if (c!=1&&c!=0) { > //diff stuff > } > > ... which strikes me as archetypically inelegant, but basically > effective. It is both. There is a better way, though. The returnCode that's being passed to the function contains the tag of the button that was pressed. There are only three choices in the pkrSheet, namely 1, 0 and -1. So this simplifies things considerably. if (returnCode == 1) { // Yay, they accepted it } else if (returnCode == -1) { // Awww, they pressed No } What I'm wondering is when the third case currently gets dealt with. Pressing "Display Key" will return 0. When is the key displayed? I hope that clears things up somewhat. -- Nick Kocharhook -- -- Rot-13 ```
 Re: if/else-if blocks in Obj-C From: Liam mac Lynne - 2003-03-26 16:05:41 ```On Wed, 26 Mar 2003, Nick Kocharhook wrote: > What I'm wondering is when the third case currently gets dealt with. > Pressing "Display Key" will return 0. When is the key displayed? > > I hope that clears things up somewhat. Indeed, the riddle inspires the solution. I'll give something a shot in the next few days & see if I can find folks on #fire to talk it over, then submit a cleaner patch here. (Thanks, Jason, for provoking a closer look; sorry I wasted bandwidth w/ a less-than-helpful patch) Slan, Liam "If we keep our pride Though Paradise is lost We will pay the price But we will not count the cost" -Rush, 'Bravado', _Roll_the_Bones_ ```
 Re: if/else-if blocks in Obj-C From: Reid Ellis - 2003-03-29 00:29:35 ```I didn't see anyone else mention this, so I thought I should.. On Wednesday, Mar 26, 2003, at 00:23 Canada/Eastern, Liam mac Lynne wrote: > c=1 //for argument's sake > if (c==1) { > //some stuff > } else if (c!=1&&c!=0) { > //diff stuff > } You don't need that overly-complicated else condition. As mentioned before, the code only flows through one block in an if/else if/else if/else statement. i.e., only the first block ["some stuff"] will get executed when c==1. The following code will perform exactly the same. c=1 //for argument's sake if (c==1) { //some stuff } else if (c!=0) { // if the code got to here, then c != 1 //diff stuff } Hope this helps, Reid ```