csp@gtenmc.UUCP (Charudutta S. Palkar) (09/12/90)
> >In article <861@gtenmc.UUCP> you write: > >> b ) a = a - ( b = ( a = a + b ) - b ); > ^ >??? Is there any way you can guarantee the value of the marker 'a'? >It could have (a) the value of 'a' immediately before the statement >is executed, or (b) the value generated by innermost (a = a + b). > >> b ) a = a ^ ( b = b ^ ( a = a ^ b )); > >Same problem here. >.... > >Anders Thulin ath@prosys.se {uunet,mcsun}!sunic!prosys!ath I am aware of this , but the point I would like to raise :- Does C mention , which instance of the variable should be used , while evaluating the expression. If neither K&R C or ANSI C specify it. I propose that such a standard be set, for one it will help removing ambiguities of evaluation ( implementation dependencies ). Some may get the impression I am for cryptic code. No I am not for cryptic code but for use of the language with all its features. If some programmers cannot use its features they might as well stop using it. C S Palkar csp - csp@gtenmc.gtetele.com csp@gtenmc.UUCP " I speak only for myself " K&R C > ANSI C
browns@iccgcc.decnet.ab.com (Stan Brown, Oak Road Systems) (09/12/90)
In article <862@gtenmc.UUCP>, csp@gtenmc.UUCP (Charudutta S. Palkar) writes: >>> b ) a = a - ( b = ( a = a + b ) - b ); >> ^ >>??? Is there any way you can guarantee the value of the marker 'a'? [... some deletions for brevity] > > Some may get the impression I am for cryptic code. No I am not > for cryptic code but for use of the language with all its features. > If some programmers cannot use its features they might as well > stop using it. > > C S Palkar I disagree. When I was in college a popular game was to write an assembler program that used every instruction opcode at least once. Could such a program be written, to illustrate "use of the language with all its features"? Of course? Was it of any earthly use, _especially_ in a commercial environment? Of course not. Dangerous in a programmer is the temptation to use a feature simply because it is there. Sort of like an house builder who puts a sink in the living room simply because he's got an extra sink lying around. Code that is not clear is bad code. Code that uses "the language with all its features" simply for the sake of using features is almost certain to be cryptic code (and therefore, IMNSHO, bad code). I don't care whether it does whether its author intended. You can be certain that no one else will be able to maintain it correctly--and that includes the original author after a lapse of a few weeks or months. On one of the more successful projects I was part of, every source module was reviewed before it was allowed into the integration builds. Code that the reviewer couldn't understand after reasonable effort was required to be rewritten. (Sometimes, in the name of time pressure, that requirement was relaxed. Guess where the system bugs showed up?) From the fact that you have to ask the question, can we infer that _you_ can not with confidence use the language "with all its features"? By your own statement does that mean you "might as well stop using it"? I don't think so. I think a more reasonable approach is to say that some features in the language are generally better understood than others. Where there are two (or more) ways to accomplish a desired result, we should be careful to choose the way that is likely to be most generally understood. If a programmer regularly uses && for & and doesn't understand the difference between = and == then I would agree he or she needs help fast--and that help might be in the form of career counseling. But I personally would give high marks in a job evaluation to anyone who choked on monstrosities like the presented above, and would argue for the discharge of anyone who, after repeated warnings, persisted in writing needlessly and egregiously obscure code. Stan Brown, Oak Road Systems, Cleveland, Ohio, U.S.A. (216) 371-0043 The opinions expressed are mine. Mine alone! Nobody else is responsible for them or even endorses them--except my cat Dexter, and he signed the power of attorney only under my threat to cut off his Cat Chow!
karl@haddock.ima.isc.com (Karl Heuer) (09/13/90)
In article <862@gtenmc.UUCP> csp@gtenmc.UUCP (Charudutta S. Palkar) writes: >Does C mention , which instance of the variable should be used , >while evaluating the expression. No, it's explicitly undefined. This is intentional. >If some programmers cannot use its features they might as well >stop using it. In this case, they should stop using *those features*, since they are not actual properties of the language. There's a tradeoff involved when deciding whether to guarantee such things. In the case of "&&", it's extremely useful to be able to write things like "if (p != NULL && isgood(p->thing)) ...", but most people don't care about "a[i++] = b[i++]" and wouldn't make heavy use of it even if it were well-defined. Leaving it explicitly undefined gives the compiler a license to rearrange the subexpressions for efficiency, which is generally considered a good thing. Karl W. Z. Heuer (karl@kelp.ima.isc.com or ima!kelp!karl), The Walking Lint