From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,4c42ac518eba0bbe X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,4c42ac518eba0bbe X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,4c42ac518eba0bbe X-Google-Attributes: gid1014db,public From: "Jos A. Horsmeier" Subject: Re: Coding for Obscurity Date: 1997/11/21 Message-ID: <34754E5E.7498D9F@and.nl>#1/1 X-Deja-AN: 291181131 References: <343fbb5a.0@news.iprolink.ch> <34466EB4.3381@dynamite.com.au> <6275dt$agm$3@news.on> <344BCED0.2D51@dynamite.com.au> <62tpap$7gh$1@darla.visi.com> <3470EF6E.F74@lysator.liu.se> <64qsf0$ccc@dfw-ixnews11.ix.netcom.com> <3474BF28.2F9F@dynamite.com.au> <34741AAF.1C7@CWA.de> Organization: AND Software B.V. Rotterdam Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++ Date: 1997-11-21T00:00:00+00:00 List-Id: Stephan Wilms wrote: > Alan E & Carmel J Brain wrote: > > firewind wrote: > > > if(!to && !(to = malloc(sizeof *to)))) return(NULL); > > > > > > The > > > if(foo() || bar()) > > > > > > construct may seem obfuscated and weird to you, it is the way the logic of > > > some people's minds work. > > No further evidence, I rest my case. > > Would anyone in comp.lang.c like to comment? > Yes, I'll volunteer a little comment: code like that has a lot of > disadvantages: it is obfuscated (it's only the author wh thinks that > the code is readable) and it's hard to debug and maintain. It sure > wouldn't pass through my code inspection. > > To explain: readability of code is not targeted at the author of the > code or maybe his office pal, it is targeted at someone having to > read and understand a whole big package of source code, to make > some important modification or to find a bug a year after the software > has been written and archived. The author might not even be available > at this moment. Even the smallest effort helps a lot. > > In detail: I would reqrite the first example like this: > > /* Sensible comment about what get's allocated. */ > if ( to == NULL ) > { > to = malloc( sizeof *to); > if ( to == NULL ) return NULL; > } Although we're talking about style and taste here (which can't be discussed IMHO), I jumped into (another thread of) this discussion because I recognized the construct above. Something like 15 years ago our team went OO (and gaga too, but that's an entirely different story ;-) C++ was hardly concipiated yet, so we turned to SmallTalk and borrowed (read 'stole') some features from that language. We were still dealing with plain old C though ... We wanted to handle 'automatic or global' objects and 'dynamic objects' (just to borrow some terminology from C++) in C. Amongst other stuff we came up with the following macros: #define NEW(x) ((x) && !((x)->dyn= NULL) || ((x)= malloc(sizeof *(x))) && ((x)->dyn= (x))) #define OLD(x) free((x)->dyn) (I'm typing this from the top of my head, so be gentle with me here) An object was represented by a simple struct. One member of such a struct 'dyn' contained the address of the struct itself if it was allocated dynamically, otherwise it would contain a NULL pointer. Given those macros we were able to do things like: void foo() { obj_t x; obj_t* y= NULL; if (NEW(&x)) /* init x; */ if (NEW(y)) /* init *y */ /* do some useful stuff with x and y here */ OLD(&x); OLD(&y); } The NEW macro registered the fact that the memory of an object was already there if it were passed the address of an existing struct. The OLD macro would peek at the 'dyn' member and pass it to free (we were simply lucky that free(NULL) did what we wanted it to do in those days, but if you tell them youngsters that, they won't believe ya ;-) I'm the one to blame for those macros. I just finished some boring project using RPG (I guess it was RPG2, but I don't recall exactly) and I did like those tagged statements, i.e. foo && bar where 'bar' would only be executed if 'foo' were true (later RISC chips even implemented this nice little feature). Maybe my braincell was damaged by my former RPG experience, but I found (and still find) the logic behind this all quite readable. So you're at least partly right: 'it's the author who thinks that this is readable'. But the fun part of this all is, that our team found this construct (and the accompanying macros) quite readable too, I wasn't the only lunatic in town ... I agree that such a construct shouldn't be written down just to inflate your ego, but a carefully constructed (or should I say 'crafted') expression like this can be highly readable for those who are at least familiar with it. But this notion leads to the question -- how qualified should software maintaining people be? If they're overqualified (and this very suitable for the job), they don't want this type of job (and vice versa is true too). kind regards, Jos aka jos@and.nl