throopw@dg_rtp.UUCP (Wayne Throop) (11/09/86)
> (poster unknown... "From:" field truncated) First a small nit. > I'd like to get at the byte stored in memory location 6. So I just > struct { char byte; } *MEMORY; > main(){char mybyte = 6->byte;} Gag. Choke. Retch. Puke. I suppose this might work on SOME mickey-mouse compiler/machine/OS combinations, but just LOOK at these gawd-awrfil questionable assumptions! - small integers cast to pointer type gives reasonable results (by no means guaranteed). - struct fields are a global namespace (not even standard C anymore) - conversions of int to pointer types will be implied by the -> operator as needed (definitely not standard C) and probably a zillion more I'm missing! Gad-zooks! > I guess what I'm saying is that until we can > create well-engineered, reliable code for one machine why are we wasting > our time worrrying about doing it for all machines at once? In other words, > portability is mostly a red herring. Good code on one machine beats > bad code on many machines every time. Well, two points I'd like to raise. First, we *CAN* (in some cases) create well-engineered, reliable code for "all machines at once" even now. It's just that the above (let's be kind here) pig swill isn't a good example of how to do it. Second, about portability being a red herring... well, come back and tell me that after you've had to port all the software you've written across three or four generations of machines (due to obsolescence of the older ones) as I've had to do, and THEN maybe I'll believe you. But probably not. And it's likely to get worse rather than better, what with shorter hardware design cycles, RISC, and so on and on. So there, you... you... smug whippersnapper you! -- "Kids these days..." "Yeah, not like the old days, when you could take 'em out and BEAT SOME SENSE INTO 'EM!!!!!" -- Wayne Throop <the-known-world>!mcnc!rti-sel!dg_rtp!throopw
throopw@dg_rtp.UUCP (Wayne Throop) (11/10/86)
> throopw@dg_rtp.UUCP (Wayne Throop) >> (poster unknown... "From:" field truncated) Hmpf. After a weekend of reflection, looks like I should raise my time-limit-between-reading-and-posting again. I'll embarrass myself by overreacting less often, I expect. But despite the fact that I expressed myself in a contentious and juvenile fashion, I think I did have a couple of points to make. I just made them poorly and emotionally, and I hereby apologize to the original poster in this subject line. I'll try to restate them more cooly, and beg you kind folks' indulgence. >> I'd like to get at the byte stored in memory location 6. So I just >> struct { char byte; } *MEMORY; >> main(){char mybyte = 6->byte;} > Gag. Choke. Retch. Puke. Awright, awright. I SAID I overreacted, right? Nevertheless, if you really want to synthesize pointers from raw bits (and dereference them), a much better way to do it is this: mybyte = *((char *)6); This is, of course, still completely non-portable, but relies less on what appears to be a really (c'mon, think up a nonjudgemental phrase Throop... uh... uh...) UNIQUE implementation of the C language. The point here is that even future revisions of the self-same compiler seem likely to me to break such fragile assumptions. On the other hand, the original poster used this example to make a very good suggestion: that every implementation of C give details of architecture and machine specific extensions and assumptions made by the compiler. I just found the "6->byte" solution so... unaesthetic as to make me... well... upset. >> I guess what I'm saying is that until we can >> create well-engineered, reliable code for one machine why are we wasting >> our time worrrying about doing it for all machines at once? In other words, >> portability is mostly a red herring. Good code on one machine beats >> bad code on many machines every time. > [bitch, bitch, bitch, insult, insult, insult] Ok, ok, so my breakfast disagreed with me that day. But seriously... machine obsolescence alone makes portability much, much more than a red herring. And more: many issues that are normally jeered at as being "silly portability quibbles" are really silly MODULARITY quibbles or silly LANGUAGE DEFINITION quibbles, and these quibbles apply even if one never intends to run the code on another machine, ever. (There, that wasn't so hard, was it Throop? And remember Throop, raise your time limit, y'hear? Your face'll be much less red and much less often, I garr-ron-TEE.) -- There is nothing in the world more helpless and irresponsible and depraved than a man in the depths of an ether binge. --- Hunter S. Thompson -- Wayne Throop <the-known-world>!mcnc!rti-sel!dg_rtp!throopw
billc@blipyramid.BLI.COM (Bill Coffin) (11/13/86)
People that think portability is not an issue in a particular piece of code almost always face, sooner or later, a nasty surprise.