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

"jacob navia" <jacob@jacob.remcomp.fr>
24 Nov 2002 01:21:07 -0500

          From comp.compilers

Related articles
[17 earlier articles]
Re: Pointers to "why C behaves like that ?" er+cc@cs.brown.edu (Manos Renieris) (2002-11-20)
Re: Pointers to "why C behaves like that ?" md9slj@mdstud.chalmers.se (Stefan Ljungstrand) (2002-11-20)
Re: Pointers to "why C behaves like that ?" torbenm@diku.dk (Torben Ęgidius Mogensen) (2002-11-24)
Re: Pointers to "why C behaves like that ?" torbenm@diku.dk (Torben Ęgidius Mogensen) (2002-11-24)
Re: Pointers to "why C behaves like that ?" nmm1@cus.cam.ac.uk (Nick Maclaren) (2002-11-24)
Re: Pointers to "why C behaves like that ?" thp@cs.ucr.edu (2002-11-24)
Re: Pointers to "why C behaves like that ?" jacob@jacob.remcomp.fr (jacob navia) (2002-11-24)
Re: Pointers to "why C behaves like that ?" nicola.musatti@objectway.it (Nicola Musatti) (2002-11-24)
Re: Pointers to "why C behaves like that ?" fjh@cs.mu.OZ.AU (Fergus Henderson) (2002-11-24)
Re: Pointers to "why C behaves like that ?" anw@merlot.uucp (Dr A. N. Walker) (2002-11-24)
Re: Pointers to "why C behaves like that ?" whopkins@alpha2.csd.uwm.edu (Mark) (2002-11-24)
Re: Pointers to "why C behaves like that ?" whopkins@alpha2.csd.uwm.edu (Mark) (2002-11-24)
Re: Pointers to "why C behaves like that ?" thp@cs.ucr.edu (2002-11-24)
[44 later articles]
| List of all articles for this month |

From: "jacob navia" <jacob@jacob.remcomp.fr>
Newsgroups: comp.compilers
Date: 24 Nov 2002 01:21:07 -0500
Organization: Wanadoo, l'internet avec France Telecom
References: 02-11-095 02-11-103
Keywords: design, types
Posted-Date: 24 Nov 2002 01:21:06 EST

> Requiring programmers to provide compilers with information that can
> be statically inferred is an unfortunate waste of human resources.
> Where types can be inferred statically, they can be annotated into the
> source code via static analysis tools. Where types cannot be
> statically inferred, the programmer ought to get a warning but the
> execution can proceed on the basis of dynamic typing. Let the
> programmer decide how he/she wishes to proceed.


fn(a)
{
        b = a;
}


How can you know what "a" is?


If you examine the whole program (this precludes a separate compilation
model like C) you can find two calls to "fn" one with:
        fn(2)
        fn(6)


Is the type of "b" an integer, a double, an unsigned char or a long long?


All those answers are correct.


Yes, that can be maybe in principle be done but with an associated enormous
cost in compiler complexity and problems.


When you support several types of integers and floating point data like in C
this kind of inference becomes extremely complex.


What do you do with arrays?


Finding the expression
        table[i] = b+8.9;


You can (maybe) deduce that table contains floating point data but how big
do you dimension it?


Yes, of course, you dimension it to have at least "i" elements. And each
time "i" becomes greater than the size of "table" you redimension it copying
the data in the new table.


        This way you generate


        for (i=0; i< b;i++) {
                table[i] = i;
        }


If "b" is 10 000 at run time you resize the table 10 000 times. NICE!


Post a followup to this message

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