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

Marco van de Voort <marcov@toad.stack.nl>
11 Dec 2002 22:24:00 -0500

          From comp.compilers

Related articles
[62 earlier articles]
Re: Pointers to "why C behaves like that ?" nmm1@cus.cam.ac.uk (Nick Maclaren) (2002-12-03)
Re: Pointers to "why C behaves like that ?" joachim_d@gmx.de (Joachim Durchholz) (2002-12-03)
Re: Pointers to "why C behaves like that ?" vugluskr@unicorn.math.spbu.ru (Roman Shaposhnick) (2002-12-07)
Re: Pointers to "why C behaves like that ?" vugluskr@unicorn.math.spbu.ru (Roman Shaposhnick) (2002-12-07)
Re: Pointers to "why C behaves like that ?" lex@cc.gatech.edu (Lex Spoon) (2002-12-11)
Re: Pointers to "why C behaves like that ?" joachim_d@gmx.de (Joachim Durchholz) (2002-12-11)
Re: Pointers to "why C behaves like that ?" marcov@toad.stack.nl (Marco van de Voort) (2002-12-11)
Re: Pointers to "why C behaves like that ?" marcov@toad.stack.nl (Marco van de Voort) (2002-12-11)
Re: Pointers to "why C behaves like that ?" lth@acm.org (Lars T Hansen) (2002-12-11)
Re: Pointers to "why C behaves like that ?" torbenm@diku.dk (2003-01-17)
Re: Pointers to "why C behaves like that ?" ralph@inputplus.co.uk (2003-03-17)
Re: Pointers to "why C behaves like that ?" skeeterdabeeterbunny@ameritech.net (skeeter da beeter bunny) (2003-03-22)
| List of all articles for this month |

From: Marco van de Voort <marcov@toad.stack.nl>
Newsgroups: comp.compilers
Date: 11 Dec 2002 22:24:00 -0500
Organization: Eindhoven University of Technology, The Netherlands
References: 02-11-095 02-11-103 02-11-128 02-11-143
Keywords: types
Posted-Date: 11 Dec 2002 22:24:00 EST

thp@cs.ucr.edu wrote:
> jacob navia <jacob@jacob.remcomp.fr> wrote:
> + 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.
>
> That same question occurs in strongly typed languages:
>
> template< class T >
> void fn( T a ) {
> T b = a;
> // ...
> }
>
> The point to generic programming is that the same piece of code can be
> used for arguments of different types.


True, but that is still a language with predeclared type. I have to
define T before I can use the code that uses the type.


I'm no expert on type interference, but IMHO this has nothing to do
with it. (the parse tree


> + 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.
>
> Type inference is well-known compiler technology and is relatively
> easy compared to some of the rest of the things that compilers must
> do.


For what? Languages that only have one base (object) type, and the
rest is handled by the interpreter?


Or for procedural compiled languages (let's take Pascal for example,
less complicated than C).


As an outsider to this discussion, I notice that the "well known
compiler technology" bit is repeated over and over again, but direct
questions (on how a particular construct works) seem to be avoided.


> + 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!
>
> I'm not suggesting that explicit declarations be prohibited. In the
> absence of explicit dimensioning, however, defaults and resizing may
> be required (as is done in many popular languages).


So it is indeed only for a certain class of languages, that compromise
on performance. (and are probably VM based)


Post a followup to this message

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