Re: Order of argument evaluation in C++, etc.

hbaker@netcom.com (Henry Baker)
Thu, 10 Aug 1995 22:06:23 GMT

          From comp.compilers

Related articles
[15 earlier articles]
Re: Order of argument evaluation in C++, etc. hbaker@netcom.com (1995-08-08)
Re: Order of argument evaluation in C++, etc. graham.matthews@pell.anu.edu.au (1995-08-08)
Re: Order of argument evaluation in C++, etc. det@sw.stratus.com (David Toland) (1995-08-08)
Re: Order of argument evaluation in C++, etc. jthill@netcom.com (1995-08-10)
Re: Order of argument evaluation in C++, etc. chase@centerline.com (1995-08-11)
Re: Order of argument evaluation in C++, etc. mfinney@inmind.com (1995-08-10)
Re: Order of argument evaluation in C++, etc. hbaker@netcom.com (1995-08-10)
Re: Order of argument evaluation in C++, etc. chase@centerline.com (1995-08-11)
Re: Order of argument evaluation in C++, etc. eggert@twinsun.com (1995-08-13)
Re: Order of argument evaluation in C++, etc. rfg@rahul.net (Ronald F. Guilmette) (1995-08-14)
Re: Order of argument evaluation in C++, etc. graham.matthews@pell.anu.edu.au (1995-08-16)
Re: Order of argument evaluation in C++, etc. bobduff@world.std.com (1995-08-16)
Re: Order of argument evaluation in C++, etc. sethml@sloth.ugcs.caltech.edu (1995-08-16)
[21 later articles]
| List of all articles for this month |
Newsgroups: comp.compilers
From: hbaker@netcom.com (Henry Baker)
Keywords: C++, optimize, design
Organization: nil organization
References: 95-07-068 95-08-081
Date: Thu, 10 Aug 1995 22:06:23 GMT

jthill@netcom.com (Jim Hill) wrote:
> One thing I do like about the no-specified-order rule is that side effects
> are otherwise less obvious in the source: that rule encourages the
> programmer to avoid unobvious side effects. In simple code, bunching a
> lot of side-effects in one statement is just bad style:


I agree that hiding side-effects may be bad style, but I'll be damned if
I'll agree to some standards committee's heavy-handed enforcement of
their near-sighted and unimaginative ideas about programming style, where
there are no technical issues.


Ada's most objectionable feature, by far, IMHO, is its holier-than-thou
attitude regarding programming style. Ada goes to a lot of trouble to
disallow features, constructs, orders of declaration, etc., based not
on any technical issues, but on some misguided notions about what makes
good programming style. Indeed, the compiler vendors have to go to
considerable _extra_ effort to disallow these things.


The time constant on getting standards implemented and de-implemented
is considerably longer than the time constant on fads in programming
styles. Let's not burden standards committees with concerns about
programming styles, or programmers with the costs of continuously
having to invent ways to subvert silly restrictions.


----


This issue is roughly equivalent to the difference between legal
standards of human behavior and personal preferences regarding dress,
sex, speech, etc.


Just as the government should stay out of the bedroom, so should
standards committees stay out of the arena of programming style.


----


To summarize:


I asked a question regarding technical issues, not stylistic issues, and
I would hope that standards committees and compiler vendors would approach
these questions based on solid technical grounds, rather than personal
prejudices.


--
www/ftp directory:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.