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

> 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!

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