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

Sander Vesik wrote:
  > Joachim Durchholz <joachim_d@gmx.de> wrote:
  >
  >>jacob navia wrote:
  >>
  >>>fn(a)
  >>>{
  >>> b = a;
  >>>}
  >>>
  >>>How can you know what "a" is?
  >>
  >>"a" is of type ANY, or Object, or Equ, or whatever happens to be the
  >>most general type that allows comparisons for equality. Type inference
  >>will not produce a more specific definition of "a" or "b" at this
  >>point. Actually that's OK - there's no need to actually nail the type
  >>down at this point.
  >
  > Depends. Do you want to be able to do separate compilation and be able
  > to get a shared library out of the code or no? Assuming that everybody
  > will have code for your library around and always does full program
  > compilation is extremely unscalable.


You can have generic code, and let the compiler generate
specializations as needed. It's not *that* difficult, all you have to
do is to keep enough information for that in the object files. (I hope
that modern object formats allow compilers to add their own
information to an object file.)


If you want to link with an external, not type-inferring language,
you'd need a separate run of the compiler to generate the specialized
version, but I don't think that this would be very difficult. (This
also answers Jacob Navia's assumption that generic code cannot be
efficient - of course it can, provided that enough information to
specialize it as needed in a specific situation is available.)


Regards,
Joachim

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