[fpc-devel] Generics

[Danny Milosavljevic]

Hi,

Am Montag, den 10.04.2006, 23:33 -0300 schrieb Flávio Etrusco:
> On 4/10/06, Danny Milosavljevic <danny.milo at gmx.net> wrote:
> > Hi,
> >
> (...)
> > > but thing is I can't see much use for generics for low level
> > > tasks.
> >
> > You need them for any kind of compile-time-type-checked collections...
> > so as long as you only do I/O port programming, you are safe... no wait,
> > only until you try to store the conversation in a list :)
> 
> You got me confused here.

bla: TList(Integer);

repeat
  i := inp(49330);
  bla.Add(i);
until i = 0;

I meant that no matter what you do, once you need any more than a static
number of values remembered, you already need them... (strings are a
special case though)

How low is "low level"?

> 
> > > There are relatively few native types that is usually ok duplicate the
> > > whole code if it need be.

Single
Double
Integer
Shortint
Longint
Cardinal
Byte
Char
WideChar
ansistring
widestring
set  (all possible set definitions)
enum (all possible enum definitions)
record (all possible record definitions)
array (all possible array definitions)
...

and one is supposed to repeat (at least) all collection object classes
for each of them? You can't be serious...

> >
> > No, the computer must do all the work it can to enable me to think of
> > what I actually want to do. If by "Duplicate", you mean _automatic_
> > duplication by the compiler, then I agree...
> 
> This is what templates are about, so this is not what I meant.
> 
> > > And it seems to me that absolutely most of
> > > the times we are working with classes instead of just single primitive
> > > variables,
> >
> > are strings classes or primitive in your mind?
> 
> My mind is FPC, so it's a primitive type.

I see. TDictionary(string, TObject) doesn't work then? (one of the most
used mappings with cgis, at least)

> 
> > > However, I'm still worried about the bloat that templates tend to add
> > > to the binary/executable
> >
> > It would add the same bloat if I implemented all the required classes by
> > hand... In the ideal case of generics handling.
> 
> Exactly. But I guess you mean "the ideal case of templates handling".
> Using "type erasure" there's no addition of code, just compile-time checks.

Those TObject-derived type parameters which don't have any of it's
methods called by the generic (on the type parameter) can be handled
that way, yes. Nothing else.

> 
> > > and about the difficulty of debugging
> > > templates (not to say that I prefer name/symbol resolution only
> > > through inheritance instead of pre-compiler/macro so much better)...
> >
> > Depends on if it's done right :)
> 
> Arguably. But considering C++ has almost 15 years of head start and
> they couldn't get it right yet, I guess it's not an easy task...

They are working pretty well now (in gcc)...

> 
> I would summarize the pros vs cons like this, please correct me if I'm wrong:
> 
> Templates' pros:
> - support of primitive types;
> - flexibility (ability to call non-virtual and non-related methods,
> operators, etc);
> - ability of coding for speed.
> 
> Type erasure generics' pros:
> - No additional generated code, no code bloat;
> - Code is easier to understand (no additional trips for symbol resolution);
> - Easy (possible ;-) to debug.
> - Much easier to implement (in the compiler) ;-)
> 
> Cheers,
> Flávio
> 

> PS. BTW I've just realized that not possible to fully replace 'type
> erasure generics' in the compiler with 'templates'... at least not as
> efficiently, right?

A mixture is best: use the same generic specialization where possible
and new specializations otherwise...

cheers,
  Danny