Re: Pointers to "why C behaves like that ?"

"Christian Bau" <christian.bau@freeserve.co.uk>
17 Nov 2002 22:54:10 -0500

          From comp.compilers

Related articles
Pointers to "why C behaves like that ?" skwong@sun80.acae.cuhk.edu.hk (WONG SAI-KEE) (2002-11-12)
Re: Pointers to "why C behaves like that ?" Gayev.D.G.=?koi8-r?Q?=3Cdg=C1ev=40mail=2Eru=3E?=@m (2002-11-13)
Re: Pointers to "why C behaves like that ?" mwotton@cse.unsw.edu.au (Mark Alexander Wolton) (2002-11-15)
Re: Pointers to "why C behaves like that ?" skwong@sun80.acae.cuhk.edu.hk (WONG SAI-KEE) (2002-11-15)
Re: Pointers to "why C behaves like that ?" jacob@jacob.remcomp.fr (jacob navia) (2002-11-15)
Re: Pointers to "why C behaves like that ?" christian.bau@freeserve.co.uk (Christian Bau) (2002-11-17)
Re: Pointers to "why C behaves like that ?" Gayev.D.G.=?iso-8859-1?Q?=3Cdg=E0ev=40mail=2Eru=3E (2002-11-17)
Re: Pointers to "why C behaves like that ?" bobduff@shell01.TheWorld.com (Robert A Duff) (2002-11-17)
Re: Pointers to "why C behaves like that ?" jamesp_spam_me_not@silver-future.com (James Powell) (2002-11-17)
Re: Pointers to "why C behaves like that ?" thp@cs.ucr.edu (2002-11-17)
Re: Pointers to "why C behaves like that ?" mwotton@cse.unsw.edu.au (Mark Alexander Wolton) (2002-11-20)
Re: Pointers to "why C behaves like that ?" thp@cs.ucr.edu (2002-11-20)
[61 later articles]
| List of all articles for this month |

From: "Christian Bau" <christian.bau@freeserve.co.uk>
Newsgroups: comp.compilers
Date: 17 Nov 2002 22:54:10 -0500
Organization: Compilers Central
References: 02-11-059 02-11-087
Keywords: design
Posted-Date: 17 Nov 2002 22:54:10 EST

  "jacob navia" <jacob@jacob.remcomp.fr> wrote:
> void updateAccount(newAmount)
> {
> CurrentAmount = ReadCurrentAccount(database);
> CurrentAmunt =CurentAmount+newAmount;
> StoreDatabase(CurrentAmount);
> }
>
> You see the problem?
>
> A typo in the spelling of the variable "CurrentAmunt" in line 2
> creates a new variable "CurrentAmunt" that receives the result of the
> addition. Since the CurrentAmount variable is stored, the account
> receives a wrong value, and there is NO WAY to spot this bug until
> runtime!
>
> This means that any error when writing down the name of a variable is
> a fatal error that will never be spotted. C prevents this by requiring
> you to explicitly state the names you want at least twice!


So a language that allows you to drop declarations lets you save five
seconds because you don't have to type "long" or "int" or whatever in
two places, and then it costs you three hours to find the bug.


It is much better if I can specify redundantly what the code is
supposed to do; that makes it more self-documenting and it is more
likely that the code doesn't compile if I make mistakes.


Post a followup to this message

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