Re: [fpc-devel] Generics-related compilation issue

[Bart via fpc-devel]

I filed a bugreport: https://bugs.freepascal.org/view.php?id=38309

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics-related compilation issue

[Bart via fpc-devel]

On Mon, Jan 4, 2021 at 11:00 PM Bart  wrote:

> So, most likely this has nothing to do with generics?
> I'm using r47193 of fpc trunk

Try to compile attached program for Win64-bit with either 3.2.0 or trunk:

Free Pascal Compiler version 3.2.0 [2020/06/04] for x86_64
Copyright (c) 1993-2020 by Florian Klaempfl and others
Target OS: Win64 for x64
Compiling c.lpr
c.lpr(17,3) Error: Can't determine which overloaded function to call
c.lpr(22) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted

Free Pascal Compiler version 3.3.1 [2021/01/04] for x86_64
Copyright (c) 1993-2020 by Florian Klaempfl and others
Target OS: Win64 for x64
Compiling c.lpr
c.lpr(15,3) Error: Can't determine which overloaded function to call
c.lpr(19,3) Error: Can't determine which overloaded function to call
c.lpr(22) Fatal: There were 2 errors compiling module, stopping
Fatal: Compilation aborted


Casting the constant to currency allows compiling in trunk (but then
fails in 3.2.0)

-- 
Bart


c.lpr
Description: Binary data
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics-related compilation issue

[Bart via fpc-devel]

On Mon, Jan 4, 2021 at 5:13 PM Bart  wrote:
>
> > What is strange to me is that the compilation issue does not happen with
> > the LazControls package alone, but only when ExCtrls package is added.
> > Moreover, the problem occurs only on 64bit, not on 32 bit. (I am on Windows)

64-bit Windows:
CompareValue(constant, currencyvariable):
3.2.0: OK.
Trunk: Error: Can't determine which overloaded function to call

CompareValue(currencyvariable, currencyvariable):
3.2.0: Error: Can't determine which overloaded function to call.
Trunk: OK

CompareValue(currencyvariable, constant):
3.2.0: OK
Trunk: Error: Can't determine which overloaded function to call

32-bit fpc 3.2.0/trunk: no problem.

So, most likely this has nothing to do with generics?
I'm using r47193 of fpc trunk

@wp: a temporary fix for compiling ExCtrls with fpc trunk would be to
assign the constant to a temp variable (in TSpinEditExBase)?

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics-related compilation issue

[Bart via fpc-devel]

On Mon, Jan 4, 2021 at 12:57 PM Werner Pamler via fpc-devel
 wrote:

> What is strange to me is that the compilation issue does not happen with
> the LazControls package alone, but only when ExCtrls package is added.
> Moreover, the problem occurs only on 64bit, not on 32 bit. (I am on Windows)

Currency on 64-bit might be the culprit. IIRC it had another datatype
then on other platforms.


-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics: issue with double inline specialization

[Sven Barth]

Am 25.10.2016 08:07 schrieb "Martok" :
> Before submitting this to the bugtracker, 3 questions: does this look
sane in
> general?

I'll try to take a look at it this weekend. But at work we're currently
rather busy (shortly before a new release of our main software), so no
promises though... (As I'd really like to have a relaxing weekend for once
;) )

> We reuse internalerror 200602061 as this is raised for the exact same
> error cause, is this style okay or should it get a fresh number?

Please use a new one. The idea of the internal errors is that the error
location can be easily found even without a callstack.

> To transform
> the example project into a testsuite test, what would be required?

If the bug report already has an example that should be fine, except you
have other cases that aren't covered by that one.

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics collections

[Maciej Izak]

2016-07-30 18:40 GMT+02:00 Sven Barth :

>  please check the changes I've made (they're mentioned both in the commit
> as well as the issue).
>
> merged into github repo

> Maybe you should add an "experimental" modifier to these types so that one
> knows that they're unstable.
>
I've made that long time ago (for most of unstable interfaces).

-- 
Best regards,
Maciej Izak
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics collections

[Sven Barth]

Am 30.07.2016 18:10 schrieb "Maciej Izak" :
>
> Impossible! :O *Finally*! Thanks Sven! Totally unexpected event. ;)

Expect the unexpected :P

> I'd like to use Generics.Collections in stable release ASAP but... IMO
best version for release is 3.2 (even 3.0.4 is probably to early). I need
to review latest changes in trunk for generics to correct library
(package?) code, because few elements in library are temporary (to
workaround bugs)  see

3.0.2 is probably too late as we're already in RC preparation phase. And as
you said 3.0.4 might be a bad idea as well if you want to rely on trunk
features.

> I have questions how to contribute in future:
>
> - shall I create ticket on bugtracker for set of my commits on github (or
for each commit separately?)?

For now please create tickets, though not necessarily for each commit, but
maybe for commits that belong together. Also please check the changes I've
made (they're mentioned both in the commit as well as the issue).

> - Is right to break interface for experimental structures (generally most
of experimental structures were introduced only for bug workarounds)

Maybe you should add an "experimental" modifier to these types so that one
knows that they're unstable.
And that's another reason to keep this in trunk only: once it's released it
would be advisable to keep breaking changes to a minimum (not that they
can't happen at all as my changes for packages have shown).

> - maybe is good idea to add me write-rights for svn only for rtl-generics
subdirectory for easily maintenance?

Let's see for a while how much work you'll still have left and then we can
talk about this again.

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics collections

[Maciej Izak]

Impossible! :O *Finally*! Thanks Sven! Totally unexpected event. ;)

I'd like to use Generics.Collections in stable release ASAP but... IMO best
version for release is 3.2 (even 3.0.4 is probably to early). I need to
review latest changes in trunk for generics to correct library (package?)
code, because few elements in library are temporary (to workaround bugs)
 see

https://github.com/dathox/generics.collections/blob/master/GenericsCompatibilityMatrix.pdf

especially we need to fix:

#26030 and #28911

#28911 will be fixed (probably) after packages release.

I have questions how to contribute in future:

- shall I create ticket on bugtracker for set of my commits on github (or
for each commit separately?)?
- Is right to break interface for experimental structures (generally most
of experimental structures were introduced only for bug workarounds)
- maybe is good idea to add me write-rights for svn only for rtl-generics
subdirectory for easily maintenance?


2016-07-29 20:01 GMT+02:00 Dimitrios Chr. Ioannidis :

> Hi,
>
>  is there a chance to merge the generics collections 34229 commit from
> trunk to 3.0 fixes ( a.k.a. 3.0.2 soon to be ) also ?
>
> regards,
>
> --
> Dimitrios Chr. Ioannidis
> ___
> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>



-- 
Best regards,
Maciej Izak
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] generics and scoping rules

[Sven Barth]

Am 08.05.2015 23:56 schrieb Martin Frb laza...@mfriebe.de:

 What are the scoping rules?

 Example:

   TLazStorageMemBase = object
   private
   const
 CNT_OFFS  = SizeOf(Pointer);
 DATA_OFFS = CNT_OFFS + (2 * SizeOf(Integer));
   private
 FMem: PByte;
 function GetCapacity: Integer; inline;
 function GetCount: Integer; inline;
 .
   end;

   generic TLazGenStorageMemT = object(TLazStorageMemBase)
 ...
 property Capacity: Integer read GetCapacity write SetCapacity;
 property Count: Integer read GetCount;
   end;


 If I specialize TLazGenStorageMem in an other unit, then I get tons of
errors, because all the privet symbols are not accessible.

 Is that intended?

I'd say that this is not intended, but I'll need to retest this with Delphi.

You forgot one very important piece of information though: what compiler
version are you using? If it's 2.6.x, then please test with 3.0.1 or 3.1.1
as there were /many/ changes since then and 2.6.4's generic support is
nothing compared to what we now have (despite there still being quite some
bugs and missing features).

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics, TObject Descendant?

[Den]

Ahh, thanks Sven! I'll see if I can post a bug report soon of it.. I'll 
use the work-around for now. :)


On 2015-02-19 12:22 AM, Sven Barth wrote:

On 18.02.2015 20:51, Den wrote:

Hi there,

Currently this code:

   TSomeObjectT = Class;
   TSomeOtherObjectT : TObject = Class(TSomeObjectT );

And finally:

   TMyObject = Class;
   TSomeOtherOtherObjectT : TMyObject = Class(TSomeOtherObjectT );

Comes up with error 'got T expected TObject' .. But TMyObject is
based off of TObject?


At seems that there are still problems if TMyObject is merely a 
forward declaration... the following works:


=== code begin ===

type
  TSomeObjectT = Class
  end;

  TSomeOtherObjectT : TObject = Class(TSomeObjectT );

  TMyObject = Class
  end;

  TSomeOtherOtherObjectT : TMyObject = Class(TSomeOtherObjectT );

=== code end ===

Note 1: this is a forward declaration XYZ = class;, this is not: 
XYZ = class(TObject);
Note2 : a generic /must not/ be a forward declaration (in this case 
TSomeObjectT).


A forward declaration of TMyObject should be valid in this case 
however, so please report a bug with an example program attached.


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics, TObject Descendant?

[Sven Barth]

On 18.02.2015 20:51, Den wrote:

Hi there,

Currently this code:

   TSomeObjectT = Class;
   TSomeOtherObjectT : TObject = Class(TSomeObjectT );

And finally:

   TMyObject = Class;
   TSomeOtherOtherObjectT : TMyObject = Class(TSomeOtherObjectT );

Comes up with error 'got T expected TObject' .. But TMyObject is
based off of TObject?


At seems that there are still problems if TMyObject is merely a forward 
declaration... the following works:


=== code begin ===

type
  TSomeObjectT = Class
  end;

  TSomeOtherObjectT : TObject = Class(TSomeObjectT );

  TMyObject = Class
  end;

  TSomeOtherOtherObjectT : TMyObject = Class(TSomeOtherObjectT );

=== code end ===

Note 1: this is a forward declaration XYZ = class;, this is not: XYZ 
= class(TObject);
Note2 : a generic /must not/ be a forward declaration (in this case 
TSomeObjectT).


A forward declaration of TMyObject should be valid in this case however, 
so please report a bug with an example program attached.


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics are still broken

[Sven Barth]

On 11.05.2012 22:58, Anthony Walter wrote:

Thanks Sven. Overall generics in Fpc are very much improved. So good
work! Your work is much appreciated!

I also experienced some different problems with classes which implement
generic interfaces where the compiler thinks that method aren't implement.

On my blog I have a page where I describe multicast events through delegates
source: http://www.codebot.org/delphi/?doc=9568

TDelegateImplT = class(TInterfacedObject, IDelegateT)

Fpc gives me some problems with the class above specifically. All the
sources are on that page and they currently work with Delphi. I can
probably boil the problem into a smaller test case.

If you want some help let me know what I can do.


If you want to report bugs it would be nice if you

1. check whether it was already reported. Most generic bugs have the tag 
generics, which you can reach here: 
http://bugs.freepascal.org/tag_view_page.php?tag_id=3 (click on 
attached issues in the upper right to see a list of all generics bugs 
(opened or closed) that are currently in Mantis)
2. add the tag generics to new bug reports, so that I can find them 
quickly.


This would help already if you discover bugs.

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics are still broken

[Anthony Walter]

Okay Sven I'll be using the bug tracker with the generics to assist in
the best way I can. I just added an issue for the problem I mentioned which
I believe was previously an undocumented issue.

Issue #22019
http://bugs.freepascal.org/view.php?id=22019
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics are still broken

[JC Chu]

It will compile correctly with the trunk version.

Generics support has been greatly improved in the trunk version; you may
want to give it a try.

On May 12, at 00:11, Anthony Walter wrote:

 Generics still have a lot of problems.  I know they've been in the works
 for years but they still fail easily. Consider the Delphi mode below, I
 get Error: Generics without specialization cannot be used as a type for
 a variable
 
 I could easily write up a whole bunch of test cases were generic still
 fail, both in Fpc and Delphi modes. If someone is considering working on
 the compiler to fix the problems with generics I can happily send them a
 bunch of test cases where the compiler currently fails.
 
 {$mode delphi}
 
 { TEnumeratorT }
 
 type
   TEnumeratorT = class abstract
   protected
 function DoGetCurrent: T; virtual; abstract;
 function DoMoveNext: Boolean; virtual; abstract;
   public
 property Current: T read DoGetCurrent;
 function MoveNext: Boolean;
   end;
 
 { TEnumerableT }
 
   TEnumerableT = class abstract
   protected
 function DoGetEnumerator: TEnumeratorT; virtual; abstract; //
 Error: Generics without specialization cannot be used as a type for a
 variable
   public
 function GetEnumerator: TEnumeratorT;
   end; 
 
 
 ___
 fpc-devel maillist  -  fpc-devel@lists.freepascal.org
 http://lists.freepascal.org/mailman/listinfo/fpc-devel

-- 
Best regards,
JC Chu
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics are still broken

[Anthony Walter]

Okay, i'll try getting trunk sources from svn and building. I'll reporting
back shortly.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics are still broken

[Anthony Walter]

The example problem I listed seems to be fixed in trunk. I'll write a few
more examples. Thank you FPC development team!
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics are still broken

[Anthony Walter]

Okay with the latest trunk version I tried compiling my generic classes. It
seems there is a problem with fpc generics in that you cannot use a generic
as a type parameter. e.g type TDictionaryK,V =
class(TEnumerableTPairK,V) ...

Given:

type
  TCollectionT = class
  end;

  TPairK,V = class
Key: K;
Value: V;
  end;

// Test

var
  TestA: TCollectionTPairString,Integer; // Fatal: Syntax error, ,
expected but  found
  TestB: TCollectionString; // Okay

The same problem occurs with classes

type
  TDictionaryAK,V = class(TCollectionTPairK,V)  // Fatal: Syntax
error, , expected but  found
  end;
  TDictionaryBK,V = class(TCollectionInteger)  // Okay
  end;
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics are still broken

[Sven Barth]

On 11.05.2012 20:10, Anthony Walter wrote:

Okay with the latest trunk version I tried compiling my generic classes.
It seems there is a problem with fpc generics in that you cannot use a
generic as a type parameter. e.g type TDictionaryK,V =
class(TEnumerableTPairK,V) ...


Yes, this is a known problem and already on my todo list (like most 
other generic bugs...)


Regards,
Sven

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics - a general question

[AvP]

First of all, thanks for your answer.
I tried to make the example as simple as possible - and simply forgot to 
allocate the memory :$

 Simply replacing object by class is not sufficient, because classes
 need to be used differently than objects.
Right, it actually needs a bit of modification in the destructor. ;-)

objects aren't used by that many persons
As I started / learned programming with TurboPascal, I habitually use objects, 
but is there a big difference for the normal user, if advanced class 
features aren't used?
Is there a difference in speed / memory consumption / code size between 
objects and classes?

Back to generics:
How much does a specialized generic class / object differ from a class / 
object, that is directly programmed (not as generic), in the binary code ?

The reason for my question is that I often read that you shouldn't use 
generics if a programm heavily depends on speed (like 3D-games). So is this 
really an issue in FreePascal (like it seems to be in C-like languages) and 
how big is the difference in speed - if there is any?

Many questions, but hopefully it will make things more clear to me.

Thanks
A.v.P.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics - a general question

[Sven Barth]

On 19.11.2011 09:33, AvP wrote:

Simply replacing object by class is not sufficient, because classes
need to be used differently than objects.

Right, it actually needs a bit of modification in the destructor. ;-)


I haven't yet tried to replicate your example with classes, so I can't 
say what exactly needs to be changed.



objects aren't used by that many persons

As I started / learned programming with TurboPascal, I habitually use objects,
but is there a big difference for the normal user, if advanced class
features aren't used?
Is there a difference in speed / memory consumption / code size between
objects and classes?


The instance sizes themselves should be rather similar between classes 
and objects, but for every class type always a VMT is created, while for 
objects at least one virtual method needs to exist for that. Also 
classes should be more easy to use as they are implicit pointers. See here:


=== source begin ===

type
  TSomeObject = object
  end;
  PSomeObject = ^TSomeObject;

  TSomeClass = class
  end;

var
  o: PSomeObject;
  c: TSomeClass;
begin
  o := New(PSomeObject);
  Dispose(o);
  c := TSomeClass.Create;
  c.Free;
end.

=== source end ===

The advantage (if one needs that) of objects is that they can live on 
the stack (like records) and that you can declare constant objects (like 
records).


Speedwise classes and objects should be rather similar.

Classes can make use of Runtime Type Information. Thus you can query the 
name of the class by just using c.ClassName or for the class type by 
c.ClassType. I don't know whether the is and as operators work for 
objects as well, but with them you can check whether a instance variable 
contains a certain subclass (is) or you can do a checked typecast (as) 
which raises an exception if the left side is not a subclass of the 
right side. Also classes can contain interfaces thus you can program to 
an interface instead of an implementation (which is sometimes seen as a 
cleaner way of object oriented programming).




Back to generics:
How much does a specialized generic class / object differ from a class /
object, that is directly programmed (not as generic), in the binary code ?

The reason for my question is that I often read that you shouldn't use
generics if a programm heavily depends on speed (like 3D-games). So is this
really an issue in FreePascal (like it seems to be in C-like languages) and
how big is the difference in speed - if there is any?



I don't know how generics are implemented in C(++), but in FPC it 
basically works like this:


* compiler parses a generic, but instead of generating code it stores 
all tokens in a token buffer inside the PPU file
* compiler parses a specialization; for this it loads the token buffer 
from the PPU file and parses that again, but replaces the generic 
parameters (in most examples T, in your example _ResType) by the 
given type (e.g. LongInt, TObject, or your TType). Thus the code 
basically appears as if you had written the same class as the generic 
but with T replaced by your given type.


So in theory there should be no speed differences.

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics - a general question

[AvP]

First, thanks for the detailed answer!

This information may be useful for others, so I put it into the wiki:
http://wiki.freepascal.org/Generics#Technical_details.

Maybe there is a better place for that...

A.v.P.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics - a general question

[Sven Barth]

On 18.11.2011 18:31, AvP wrote:

1. Is this behavior intended (generic objects)?
I didn't find anything like that in the docs


It's at least not forbidden. I can imagine though that it was forgotten 
to document as objects aren't used by that many persons (and thus they 
are forgotten rather easily). They are rather similary handled by the 
compiler as class (at least in regards to parsing; the code generated 
is of course different).




2. Replacing object at (1) with class gives an error when compiling



Simply replacing object by class is not sufficient, because classes 
need to be used differently than objects. If you need help regarding 
this, I can provide you one if you want or you can read this: 
http://wiki.freepascal.org/Object_Oriented_Programming_with_FreePascal_and_Lazarus



3. In my case the specialization should only work if _ResType is TType or
derived, as certain fields and functions/procedures are read / executed

Is there currently a way to do this typesafe (my version is a hack, I believe)
?
If not, maybe this would be an interesting feature for FPC.


Currently this is not possible, but I plan to add that, because of 
Delphi compatibility. The feature that you want is called constraints 
and the declaration of TManager will then look like this:


generic TManager_ResType: TType = object
  ...
end;

The compiler will then also be able to check whether you are using 
methods that are valid for the passed type.


Regarding your code:


  constructor TManager.Create;
  begin
SetLength(Resource, 2);
Resource[0] := New(PResType, Init); // You need to allocate the memory 
for the object

// Resource[0]^.Init;  // No problem here

WriteLn('Manager.Create done...');
  end;

  destructor TManager.Destroy;
  begin

Dispose(Resource[0], Done); // Free the memory allocated earlier
// Resource[0]^.Done;  // No problem here

WriteLn('Manager.Destroy done...');
  end;


Please note: While this is how it SHOULD work this does currently not 
work with any version of the compiler except maybe my generic branch (I 
haven't tested that yet).


As a workaround you can do this:

In TManager.Create:
Resource[0] := New(PResType);
Resource[0]^.Init;

In TManager.Destroy:
Resource[0]^.Dispose;
Dispose(Resource[0]);

This will issue two warnings though, but it works.

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics - a general question

[Sven Barth]

On 18.11.2011 21:12, Sven Barth wrote:

Please note: While this is how it SHOULD work this does currently not
work with any version of the compiler except maybe my generic branch (I
haven't tested that yet).


Ok, I have tested that with my branch and it doesn't work there either. 
After thinking a bit about that, it's logical and expected. So for my 
solution written in the previous mail to work we need the generic 
constraints.


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics in FPC have many problems

[Sven Barth]

Am 30.08.2011 03:06, schrieb Anthony Walter:

Tonight I tried to make all from your branch and wasn't able to build.
This is a the output I got:

http://pastebin.com/GQh5XA2w

I am guessing your build requires a working version of your fpc binary
to build itself.


The errors you see are already when compiling the RTL with the newly 
compiled compiler. As I said: compiling fgl is currently broken.

I'd suggest you to do the following:
Replace fgl.pp in rtl/objpas/ with an empty unit of the same name (empty 
here means containing unit fgl; interface implementation end.). You 
can't use the basic generic classes then, but for tests they aren't 
necessary. ^^
Then issue the following commands (I assume you start in the base 
directory of the checkout):


=== commands begin ===
cd compiler
make cycle
cd ../rtl
make clean all
=== commands end ===

You'll have a new compiler as compiler/ppc386 (assuming you're on a x86 
system; it will be named approbiately for other systems) and a compiled 
RTL in rtl/units/PLATFORM-OS (e.g. rtl/units/i386-linux). You can then 
compile programs with the following command (I assume FPCDIR to be set 
to the checkout's base directory, and the current platform to be 
i386-linux ):


=== command begin ===

$FPCDIR/compiler/ppc386 -n -Fu$FPCDIR/rtl/units/i386-linux 
[OTHER-OPTIONS] yourtest.pas


=== command end ===


Also, I wrote a few of pretty clean test cases in Delphi 2010 Today when
I had some downtime from my other work. I'd be interested in integrating
them cleanly into your tests and helping the fpc community any way I can.


If you write them in a way that they adhere to the same basic pattern as 
other tests in FPC then they can easily be integrated (just take a look 
at the existing generic tests to see what I mean). I you have questions 
regarding this, please feel free to ask :)



Finally, I think I looked at your change log. I guess the last check in
you did was on July 16? I I reading that right?


The SVN branch is a bit behind of my local GIT one, but not that much. I 
didn't have much time the last few weeks (and the coming weeks as well) 
as I'm working on my bachelor thesis :)


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics in FPC have many problems

[Paul Ishenin]

29.08.2011 21:52, Anthony Walter wrote:
Jump to So here are some of the problems I've found with fpc 
generics if you don't want to read the backstory.

...
And if someone ever does intent to fix generics in FPC, there are a 
whole slew of errors that they already bring into the compiler. I'll 
make a list of examples of those errors at a later time, but they 
inner workings of generics should be redone to remove the 
specialization requirement before those errors are addressed.
Yes. These are known problems and you would found even more a year ago. 
Sven Barth now trying to fix exising problems and implement missing things.


If you wish to try fix them yourself you need to study how parser part 
of the compiler works.


Best regards,
Paul Ishenin.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics in FPC have many problems

[Anthony Walter]

On Mon, Aug 29, 2011 at 10:15 AM, Paul Ishenin webpi...@mail.ru wrote:

 Yes. These are known problems and you would found even more a year ago.
 Sven Barth now trying to fix exising problems and implement missing things.

 If you wish to try fix them yourself you need to study how parser part of
 the compiler works.

 Best regards,
 Paul Ishenin.


Paul, thanks for the reply. Did you mean to say that the generics are
actually being improved ... that is that someday you might be able to say:

procedure TMyNonGenericClass.MyGenericMethodT(List: TListT);

Or that the random seeming bugs with the existing way generics works is
being fixed?

I think the way generics work needs to fixed first, to allow code like above
to work. Then the strange bugs surrounding the new way they work can be
addressed.

One thing that basically needs to go away is the need to specialize a
generic. This causes problems even in {$mode delphi}.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics in FPC have many problems

[Anthony Walter]

Oh, and FPC generics really need the ability to add constraints ...

e.g. type TObjectListT: TObject = class TListT ... end;
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics in FPC have many problems

[Jonas Maebe]

On 29 Aug 2011, at 16:23, Anthony Walter wrote:


Paul, thanks for the reply. Did you mean to say that the generics are
actually being improved ... that is that someday you might be able  
to say:


procedure TMyNonGenericClass.MyGenericMethodT(List: TListT);

Or that the random seeming bugs with the existing way generics works  
is

being fixed?


You can see the details of what has already happened by looking at the  
svn logs for http://svn.freepascal.org/svn/fpc/branches/svenbarth/generics 
, e.g.:
  svn log http://svn.freepascal.org/svn/fpc/branches/svenbarth/ 
generics | less


The changes specific to that branch start with r17316. As far as  
{$mode delphi} is concerned, the eventual goal is to have a completely  
Delphi-compatible generics syntax.



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics in FPC have many problems

[Anthony Walter]

Thanks Jonas. Btw, where would be a good place to follow your progress on
JVm support?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics in FPC have many problems

[Jonas Maebe]

On 29 Aug 2011, at 16:50, Anthony Walter wrote:


Btw, where would be a good place to follow your progress on
JVm support?


Here :) And also the svn commit log of http://svn.freepascal.org/svn/fpc/branches/jvmbackend 
, as well as http://wiki.freepascal.org/FPC_JVM and its subpages  
(probably easiest via http://wiki.freepascal.org/ 
Special:Recentchanges ).



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics in FPC have many problems

[Sven Barth]

Hi!

As Paul and Jonas already told you, I'm currently working on improving 
the compilers generic implementation. As you have noticed it currently 
doesn't support generic methods and constraints at all. Also the generic 
implementation in mode Delphi isn't working correctly as you've noticed. 
Inline specialications (those without using type foobar = foobar) 
don't work either.


For this I have found the following tasks:
* allow declaring and implementing generics with the Delphi syntax while 
keeping the FPC syntax supported (this is an important point regarding 
backwards compatibility); state: working
* allow the declarations of multiple generics with the same name (e.g. 
foot =... foo t, s = ...); state: mostly working
* allow inline specializations; state: partly working inside 
implementations; inside declarations this needs to be tested

* allow nested specializations: not started
* allow nested generics: not started
* implement generic methods: not started
* implement constraints: not started

My plan is to merge the changes from my branch to trunk after the first 
three points are done (the third one at least mostly as inline 
specializations are rather fragile) to reduce the differences between 
those to branches. Then I'll start working on either generic methods or 
constraints (depends on my mood then).


Please keep in mind that working on the generics feature isn't an easy 
task, so I can't give you an estimate when the one or other improvement 
will be available.


If you want you can test around with my branch, but please keep in mind 
that it's a work in progress and that compilation of the compiler or the 
RTL might also be broken from time to time (currently the fgl unit 
doesn't compiler for example).



And if someone ever does intent to fix generics in FPC, there are a whole slew 
of errors that they already bring into the compiler. I'll make a list of 
examples of those errors at a later time, but they inner workings of generics 
should be redone to remove the specialization requirement before those errors 
are addressed.


If you do such an error list then please provide a single program for 
each problem you encounter so that it might be integrated into FPC's 
test suite which will ease fixing the problem.


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics in FPC have many problems

[Anthony Walter]

On Mon, Aug 29, 2011 at 11:19 AM, Sven Barth pascaldra...@googlemail.comwrote:

 Hi!

 As Paul and Jonas already told you, I'm currently working on improving the
 compilers generic implementation. As you have noticed it currently doesn't
 support generic methods and constraints at all. Also the generic
 implementation in mode Delphi isn't working correctly as you've noticed.
 Inline specialications (those without using type foobar = foobar) don't
 work either.

 For this I have found the following tasks:
 * allow declaring and implementing generics with the Delphi syntax while
 keeping the FPC syntax supported (this is an important point regarding
 backwards compatibility); state: working
 * allow the declarations of multiple generics with the same name (e.g.
 foot =... foo t, s = ...); state: mostly working
 * allow inline specializations; state: partly working inside
 implementations; inside declarations this needs to be tested
 * allow nested specializations: not started
 * allow nested generics: not started
 * implement generic methods: not started
 * implement constraints: not started

 My plan is to merge the changes from my branch to trunk after the first
 three points are done (the third one at least mostly as inline
 specializations are rather fragile) to reduce the differences between those
 to branches. Then I'll start working on either generic methods or
 constraints (depends on my mood then).

 Please keep in mind that working on the generics feature isn't an easy
 task, so I can't give you an estimate when the one or other improvement will
 be available.

 If you want you can test around with my branch, but please keep in mind
 that it's a work in progress and that compilation of the compiler or the RTL
 might also be broken from time to time (currently the fgl unit doesn't
 compiler for example).


  And if someone ever does intent to fix generics in FPC, there are a whole
 slew of errors that they already bring into the compiler. I'll make a list
 of examples of those errors at a later time, but they inner workings of
 generics should be redone to remove the specialization requirement before
 those errors are addressed.


 If you do such an error list then please provide a single program for each
 problem you encounter so that it might be integrated into FPC's test suite
 which will ease fixing the problem.

 Regards,
 Sven


Wow, Sven, thanks for the reply, and most definitely thanks for working on
FPC. Anything I can do to help I'll do. Last week I sent patches to fix
issues with Lazarus CodeTools and the new generic syntax which basically
caused a lot of problems in the IDE.

I'll be on freenode irc in both #fpc and #lararus-ide for the next few weeks
at least. Where do you want me to send some unit tests/test program source?
The issue tracker? One issue for each test that or all in all tests in one
issue?

Also be sure to let me know if there is anything I can do for you. I don't
have much experience with OSS collaboration, but am motivated to get things
done and done the right way.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics in FPC have many problems

[Sven Barth]

Wow, Sven, thanks for the reply, and most definitely thanks for working
on FPC. Anything I can do to help I'll do. Last week I sent patches to
fix issues with Lazarus CodeTools and the new generic syntax which
basically caused a lot of problems in the IDE.

I'll be on freenode irc in both #fpc and #lararus-ide for the next few
weeks at least. Where do you want me to send some unit tests/test
program source? The issue tracker? One issue for each test that or all
in all tests in one issue?

Also be sure to let me know if there is anything I can do for you. I
don't have much experience with OSS collaboration, but am motivated to
get things done and done the right way.


First it might be good if you'd try to compile my branch and play around 
with taht. Do you know how to use svn?
Because there you can find all generic related tests that are currently 
available in the folder tests/test/. They are all named tgenericXX.pp. 
So if you find a test there that describes one of your problems then 
I've already tackled it.


Otherwise it might be best if you prepare a list of your problems and 
post them here. This way I can easily decide which ones are already on 
my ToDo list, which are already locally fixed or are serious ones that 
should be put to the bug tracker. With that I'll tell you for which ones 
I'll need tests.


If you post your problems though, then please try to find a simple test 
case that by itself could already be compiled with minor 
modifications/additions, because in your original posting there is quite 
a bit of noise in the code, if you understand what I mean ;)


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics in FPC have many problems

[Anthony Walter]

Sven,

Tonight I tried to make all from your branch and wasn't able to build.
This is a the output I got:

http://pastebin.com/GQh5XA2w

I am guessing your build requires a working version of your fpc binary to
build itself.

Also, I wrote a few of pretty clean test cases in Delphi 2010 Today when I
had some downtime from my other work. I'd be interested in integrating them
cleanly into your tests and helping the fpc community any way I can.

Finally, I think I looked at your change log. I guess the last check in you
did was on July 16? I I reading that right?


r18005 | svenbarth | 2011-07-16 12:19:33 -0400 (Sat, 16 Jul 2011) | 1 line

Rebase to revision 18000

r18004 | svenbarth | 2011-07-16 10:13:56 -0400 (Sat, 16 Jul 2011) | 1 line

pexpr.pas, sub_expr: Added support for as and is operators if the right
hand side is an inline specialization (currently detected by the next token
being a ). This could potentially introduce some problems if the right
hand side isn't a specialization but a  comparison together with some
overloaded operators (I still need to find a case for such a problem)...
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics - anyone working on them?

[Florian Klämpfl]

Am 23.11.2010 20:18, schrieb Aleksa Todorovic:
 Hi!
 
 I've attached several patches regarding generics some time ago
 (http://bugs.freepascal.org/view.php?id=15875,
 http://bugs.freepascal.org/view.php?id=11777), but there was no
 response regarding them. Is anyone from fpc developers working on
 generics currently (improving/maintaining/fixing/applying patches)? 

I do usually, but I had no time the last days to look into the bug tracker.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics syntax error

[Sven Barth]

Am 29.09.2010 00:54, schrieb Willibald Krenn:

Hi!


I'm having this issue, too, but with 2.4.3.


The following example code fails with FPC 2.4.2 RC1 as well (system is
i386-win32):


Tried that with trunk and it compiled fine. (FPC 2.5 on win64)


I also tested with a 2.5.1 version from August (I don't remember the 
correct date currently) yesterday evening and it worked as well. (on 
i386-linux)


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics syntax error

[Sven Barth]

Am 29.09.2010 09:06, schrieb Sven Barth:

Am 29.09.2010 00:54, schrieb Willibald Krenn:

Hi!


I'm having this issue, too, but with 2.4.3.


The following example code fails with FPC 2.4.2 RC1 as well (system is
i386-win32):


Tried that with trunk and it compiled fine. (FPC 2.5 on win64)


I also tested with a 2.5.1 version from August (I don't remember the
correct date currently) yesterday evening and it worked as well. (on
i386-linux)


I looked around a bit more. There already exists a bug report from April 
for this: http://bugs.freepascal.org/view.php?id=16121


I manually merged 14176 to my 2.4.3 working copy now (as mentioned in 
the report) and I also needed to merge 14243 to resolve the remaining 
issues.


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics syntax error

[Sven Barth]

Am 27.09.2010 14:21, schrieb Sven Barth:

I'm having this issue, too, but with 2.4.3.


The following example code fails with FPC 2.4.2 RC1 as well (system is 
i386-win32):




program generictest;

{$mode objfpc}{$H+}

uses
  fgl;

type
  TTest = specialize TFPGListTObject;

begin
end.



2.4.0 works without problems here.
2.4.3 has the same problem (as mentioned in the previous mail).

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics syntax error

[Willibald Krenn]

Hi!


I'm having this issue, too, but with 2.4.3.


The following example code fails with FPC 2.4.2 RC1 as well (system is
i386-win32):


Tried that with trunk and it compiled fine. (FPC 2.5 on win64)

Cheers,
 Willi
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics syntax error

[Sven Barth]

Am 22.09.2010 15:59, schrieb Felipe Monteiro de Carvalho:

Hello,

Has anyone experienced issues with generics? I have the following code:

unit cdescreen;

{$mode delphi}

interface

uses
   // LCL, RTL, FCL
   Classes, SysUtils, Controls, Graphics, LCLType, SDFData, fpimage,
   fgl,
   //
   cdeconfig, cdeprovinces, cdeutils, cdegame, cdetypes, dlgstatus;

type

   TCDEScreen = class;

   { TCDEDrawerDelegate }

   TCDEDrawerDelegate = class
   public
 Owner: TCDEScreen;
 procedure HandleMouseDown(Sender: TObject; Button: TMouseButton;
Shift:TShiftState; X,Y:Integer); virtual; abstract;
 procedure HandleMouseUp(Sender: TObject; Button: TMouseButton;
Shift:TShiftState; X,Y:Integer); virtual; abstract;
 procedure HandleMouseMove(Sender: TObject; Shift: TShiftState; X,
Y: Integer); virtual; abstract;
 procedure Prepare; virtual; abstract;
   end;

   TDrawerDelegateList = specialize TFPGListTCDEDrawerDelegate;
...
cdescreen.pas(29,63) Fatal: Syntax error, ; expected but  found

If I change the line to   TDrawerDelegateList = specialize
TFPGListTCDEDrawerDelegate;

then it says:

cdescreen.pas(29,63) Fatal: Syntax error,  expected but ; found

o.O FPC 2.4.0 on Windows

I couldn't find anything in the bug tracker

Changing the mode to objfpc doesn't change anything

thanks,


I'm having this issue, too, but with 2.4.3.

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Jonas Maebe]

On 21 Oct 2009, at 19:08, David B Copeland wrote:


On Wed, 2009-10-21 at 15:54 +0200, Jonas Maebe wrote:

Generics still don't work 100%,


In what way is Generics not 100%?


There are problems with using inheritance, e.g. http://bugs.freepascal.org/view.php?id=12249 
 and http://svn.freepascal.org/svn/fpc/trunk/tests/test/tgeneric16.pp


Another compiler crash: http://bugs.freepascal.org/view.php?id=12810

It's not possible to use references to not yet fully specialised  
types, e.g. http://bugs.freepascal.org/view.php?id=11777


Assembler does not work in generics.

There are some problems with inline and generics.


Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[David B Copeland]

On Wed, 2009-10-21 at 15:54 +0200, Jonas Maebe wrote:
 On 21 Oct 2009, at 14:55, Marco van de Voort wrote:
 

 Generics still don't work 100%, 
 
 
 Jonas
 

In what way is Generics not 100%?

Dave Copeland.



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics basic library

[Graeme Geldenhuys]

Hi Felipe,

I have never gotten onto the band wagon regarding Generics. I have
only seen the word being tossed around on the mailing lists and
newsgroups.  Do you maybe have a nice link explaining Generics, what
benefits it has over TList (TObjectList and friends) and what I would
use it for?  I gather FPC 2.2.0 has support for Generics?

Regards,
  - Graeme -


On 17/01/2008, Felipe Monteiro de Carvalho
[EMAIL PROTECTED] wrote:
 Hello,

 I was coding and I suddently saw that need to use a typed list. I went
 with TFPList, but considering we already have compiler support I
 thougth that maybe we could have a basic library with useful classes
 using generics. I searched on fpc 2.2.0 sources a lot, but I couldn't
 find anything.

 I was thinking on the lines of: TGenericListT = class

 Does something similar already exist?

 If not, maybe I can find some time to write something to start with.
 Any ideas about unit name, location on fpc sources, if it's useful at
 all, what it should contain, etc, for that?

 thanks,
 --
 Felipe Monteiro de Carvalho
 ___
 fpc-devel maillist  -  fpc-devel@lists.freepascal.org
 http://lists.freepascal.org/mailman/listinfo/fpc-devel



-- 
Regards,
  - Graeme -


___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics basic library

[Peter Vreman]

At 20:40 17-1-2008, you wrote:

Hello,

I was coding and I suddently saw that need to use a typed list. I went
with TFPList, but considering we already have compiler support I
thougth that maybe we could have a basic library with useful classes
using generics. I searched on fpc 2.2.0 sources a lot, but I couldn't
find anything.

I was thinking on the lines of: TGenericListT = class

Does something similar already exist?

If not, maybe I can find some time to write something to start with.
Any ideas about unit name, location on fpc sources, if it's useful at
all, what it should contain, etc, for that?


See the fgl unit in current 2.2.1 or 2.3.1. Generics were not stable 
enough in the past to have the unit already enabled in 2.2.0.





Peter

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics basic library

[Felipe Monteiro de Carvalho]

On Jan 17, 2008 9:01 PM, Peter Vreman [EMAIL PROTECTED] wrote:
 See the fgl unit in current 2.2.1 or 2.3.1. Generics were not stable
 enough in the past to have the unit already enabled in 2.2.0.

Oh, thanks. In my search I had actually found this unit, but then I
looked at the unit name and said: Oh, pretty cool they are using
generics on the opengl bindings, but doesn't help me much =)

-- 
Felipe Monteiro de Carvalho
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Florian Klaempfl]

Mattias Gaertner schrieb:

On Thu, 16 Aug 2007 23:31:25 +0200 (CEST)
Michael Van Canneyt [EMAIL PROTECTED] wrote:


[...]

Why is the local variable block needed?

It is not. I asked the same question. It was added for symmetry
reasons: if a local type block is allowed, then a var block should
also be allowed.

But they are not different from local fields.


Strange. ok.

What local types are/will be allowed?

For example, this is currently not allowed:

  generic TTreeT = class(TObject)
  type public 
TTreeNode = specialize TNodeT;

  end;

And this neither:

  generic TTreeT = class(TObject)
  type public
TTreeNode = class
  Data: T;
end;
  end;


OTOH records and pointers are allowed.
Will this stay, or is this just not yet implemented?


Is there a need to support this?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Michael Van Canneyt]

On Fri, 17 Aug 2007, Florian Klaempfl wrote:

 Mattias Gaertner schrieb:
  On Thu, 16 Aug 2007 23:31:25 +0200 (CEST)
  Michael Van Canneyt [EMAIL PROTECTED] wrote:
  
   [...]
Why is the local variable block needed?
   It is not. I asked the same question. It was added for symmetry
   reasons: if a local type block is allowed, then a var block should
   also be allowed.
  
   But they are not different from local fields.
  
  Strange. ok.
  
  What local types are/will be allowed?
  
  For example, this is currently not allowed:
  
generic TTreeT = class(TObject)
type public   TTreeNode = specialize TNodeT;
end;
  
  And this neither:
  
generic TTreeT = class(TObject)
type public
  TTreeNode = class
Data: T;
  end;
end;
  
  
  OTOH records and pointers are allowed.
  Will this stay, or is this just not yet implemented?
 
 Is there a need to support this?

Well, it seems rather strange that the type block would not allow all
possible types.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Florian Klaempfl]

Michael Van Canneyt schrieb:


On Fri, 17 Aug 2007, Florian Klaempfl wrote:


Mattias Gaertner schrieb:

On Thu, 16 Aug 2007 23:31:25 +0200 (CEST)
Michael Van Canneyt [EMAIL PROTECTED] wrote:


[...]

Why is the local variable block needed?

It is not. I asked the same question. It was added for symmetry
reasons: if a local type block is allowed, then a var block should
also be allowed.

But they are not different from local fields.

Strange. ok.

What local types are/will be allowed?

For example, this is currently not allowed:

  generic TTreeT = class(TObject)
  type public   TTreeNode = specialize TNodeT;
  end;

And this neither:

  generic TTreeT = class(TObject)
  type public
TTreeNode = class
  Data: T;
end;
  end;


OTOH records and pointers are allowed.
Will this stay, or is this just not yet implemented?

Is there a need to support this?


Well, it seems rather strange that the type block would not allow all
possible types.


Only a few types can be generic as well. Nested classes cause a lot of 
hidden pitfalls, that's why they aren't allowed.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Michael Van Canneyt]

On Fri, 17 Aug 2007, Florian Klaempfl wrote:

 Michael Van Canneyt schrieb:
  
  On Fri, 17 Aug 2007, Florian Klaempfl wrote:
  
   Mattias Gaertner schrieb:
On Thu, 16 Aug 2007 23:31:25 +0200 (CEST)
Michael Van Canneyt [EMAIL PROTECTED] wrote:
   
 [...]
  Why is the local variable block needed?
 It is not. I asked the same question. It was added for symmetry
 reasons: if a local type block is allowed, then a var block should
 also be allowed.

 But they are not different from local fields.
Strange. ok.
   
What local types are/will be allowed?
   
For example, this is currently not allowed:
   
  generic TTreeT = class(TObject)
  type public   TTreeNode = specialize TNodeT;
  end;
   
And this neither:
   
  generic TTreeT = class(TObject)
  type public
TTreeNode = class
  Data: T;
end;
  end;
   
   
OTOH records and pointers are allowed.
Will this stay, or is this just not yet implemented?
   Is there a need to support this?
  
  Well, it seems rather strange that the type block would not allow all
  possible types.
 
 Only a few types can be generic as well. Nested classes cause a lot of hidden
 pitfalls, that's why they aren't allowed.

OK, probably I should add this to the docs. I assume all types can be
defined except classes and generics ?

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Mattias Gaertner]

On Fri, 17 Aug 2007 10:20:13 +0200 (CEST)
Michael Van Canneyt [EMAIL PROTECTED] wrote:

[...]
 What local types are/will be allowed?

 For example, this is currently not allowed:

   generic TTreeT = class(TObject)
   type public   TTreeNode = specialize TNodeT;
   end;

 And this neither:

   generic TTreeT = class(TObject)
   type public
 TTreeNode = class
   Data: T;
 end;
   end;


 OTOH records and pointers are allowed.
 Will this stay, or is this just not yet implemented?
Is there a need to support this?

I don't need them.
I'm just asking for the codetools.
So I guess the answer is: Will stay. (read: there are no
further plans).


   Well, it seems rather strange that the type block would not allow
   all possible types.
  
  Only a few types can be generic as well. Nested classes cause a lot
  of hidden pitfalls, that's why they aren't allowed.
 
 OK, probably I should add this to the docs. I assume all types can be
 defined except classes and generics ?

.. and objects and interfaces.

It seems generic objects and interfaces are allowed, but this
is not yet documented.

What about generic records? Will they be implemented?


Mattias
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Micha Nelissen]

Mattias Gaertner wrote:

For example, this is currently not allowed:

  generic TTreeT = class(TObject)
  type public 
TTreeNode = specialize TNodeT;

  end;


Shouldn't this be allowed?

Perhaps it can only work with a complete TTreeNode description, probably 
the TNode is specific for use by TTree anyway. But that would limit it 
to being a record.


Micha
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Bram Kuijvenhoven]

Florian Klaempfl wrote:

Mattias Gaertner schrieb:

For example, this is currently not allowed:

  generic TTreeT = class(TObject)
  type public TTreeNode = specialize TNodeT;
  end;

And this neither:

  generic TTreeT = class(TObject)
  type public
TTreeNode = class
  Data: T;
end;
  end;


OTOH records and pointers are allowed.
Will this stay, or is this just not yet implemented?


Is there a need to support this?


Imho the example given by Mattias demonstrates that a similar construct would 
be desirable; or is there another way to accommodate for the aggregation of 
generic classes?

I think TTree/TNode is a typical example where you'd like to use the generic 
type used for TTree to create the corresponding TNode.

type
 generic TNodeT = class
   type TChildList = TListTNode; // and how about this?
   Data:T;
   Children:TChildList;
 end;

 generic TTreeT = class
   type TTreeNode = specialize TNodeT;
   Root:TTreeNode;
   GetNode(Index:integer):TTreeNode;
   GetNodeData(Index:integer):T;
 end;

...

function TTree.GetNodeData(Index:integer):T;
begin
 Result:=GetNode(Index).Data;
end;


Regards,

Bram
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Jesus Reyes]

--- Michael Van Canneyt [EMAIL PROTECTED] escribió:

 
 
 On Thu, 16 Aug 2007, Mattias Gaertner wrote:
 
  
  What is the state and future plans of generics?
  I only found the wiki page
  
  http://wiki.lazarus.freepascal.org/Generics
  
  which does not even mention the current syntax.
 
 The current syntax is descibed in the docs, reference manual.
 There is a chapter about generics. Feel free to comment on it;
 any omissions, I'll be glad to fill them in (as far as I can,
 I don't use generics myself).
 
 Michael.

Images are so big that is difficult to follow the diagrams..

Jesus Reyes A. 



  

¡Sé un mejor besador!
Comparte todo lo que sabes sobre besos.  
http://mx.yahoo.com/promos/mejorbesador.html
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Jesus Reyes]

--- Jesus Reyes [EMAIL PROTECTED] escribió:

 
 --- Michael Van Canneyt [EMAIL PROTECTED] escribió:
 
  
  
  On Thu, 16 Aug 2007, Mattias Gaertner wrote:
  
   
   What is the state and future plans of generics?
   I only found the wiki page
   
   http://wiki.lazarus.freepascal.org/Generics
   
   which does not even mention the current syntax.
  
  The current syntax is descibed in the docs, reference manual.
  There is a chapter about generics. Feel free to comment on it;
  any omissions, I'll be glad to fill them in (as far as I can,
  I don't use generics myself).
  
  Michael.
 
 Images are so big that is difficult to follow the diagrams..

sorry I forgot to put at least a link:

http://www.freepascal.org/docs-html/ref/refse38.html

 
 Jesus Reyes A. 



  

¡Sé un mejor besador!
Comparte todo lo que sabes sobre besos.  
http://mx.yahoo.com/promos/mejorbesador.html
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Michael Van Canneyt]

On Thu, 16 Aug 2007, Jesus Reyes wrote:

 
 --- Michael Van Canneyt [EMAIL PROTECTED] escribió:
 
  
  
  On Thu, 16 Aug 2007, Mattias Gaertner wrote:
  
   
   What is the state and future plans of generics?
   I only found the wiki page
   
   http://wiki.lazarus.freepascal.org/Generics
   
   which does not even mention the current syntax.
  
  The current syntax is descibed in the docs, reference manual.
  There is a chapter about generics. Feel free to comment on it;
  any omissions, I'll be glad to fill them in (as far as I can,
  I don't use generics myself).
  
  Michael.
 
 Images are so big that is difficult to follow the diagrams..

Please use the PDF version, not the HTML version. The HTML is generated
from the LaTeX, but the quality is in general rather poor.

Michael.___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Mattias Gaertner]

On Thu, 16 Aug 2007 14:59:47 -0500 (CDT)
Jesus Reyes [EMAIL PROTECTED] wrote:

 
 --- Jesus Reyes [EMAIL PROTECTED] escribió:
 
  
  --- Michael Van Canneyt [EMAIL PROTECTED] escribió:
  
   
   
   On Thu, 16 Aug 2007, Mattias Gaertner wrote:
   

What is the state and future plans of generics?
I only found the wiki page

http://wiki.lazarus.freepascal.org/Generics

which does not even mention the current syntax.
   
   The current syntax is descibed in the docs, reference manual.
   There is a chapter about generics. Feel free to comment on it;
   any omissions, I'll be glad to fill them in (as far as I can,
   I don't use generics myself).
   
   Michael.
  
  Images are so big that is difficult to follow the diagrams..
 
 sorry I forgot to put at least a link:
 
 http://www.freepascal.org/docs-html/ref/refse38.html

Thanks.

Maybe the wiki page should be marked as obsolete and a link to the
reference should be added? 

Why is the local variable block needed?


Mattias
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Michael Van Canneyt]

On Thu, 16 Aug 2007, Mattias Gaertner wrote:

 On Thu, 16 Aug 2007 14:59:47 -0500 (CDT)
 Jesus Reyes [EMAIL PROTECTED] wrote:
 
  
  --- Jesus Reyes [EMAIL PROTECTED] escribió:
  
   
   --- Michael Van Canneyt [EMAIL PROTECTED] escribió:
   


On Thu, 16 Aug 2007, Mattias Gaertner wrote:

 
 What is the state and future plans of generics?
 I only found the wiki page
 
 http://wiki.lazarus.freepascal.org/Generics
 
 which does not even mention the current syntax.

The current syntax is descibed in the docs, reference manual.
There is a chapter about generics. Feel free to comment on it;
any omissions, I'll be glad to fill them in (as far as I can,
I don't use generics myself).

Michael.
   
   Images are so big that is difficult to follow the diagrams..
  
  sorry I forgot to put at least a link:
  
  http://www.freepascal.org/docs-html/ref/refse38.html
 
 Thanks.
 
 Maybe the wiki page should be marked as obsolete and a link to the
 reference should be added? 

Maybe, yes.

 
 Why is the local variable block needed?

It is not. I asked the same question. It was added for symmetry reasons:
if a local type block is allowed, then a var block should also be allowed.

But they are not different from local fields.

Michael.___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Mattias Gaertner]

On Thu, 16 Aug 2007 23:31:25 +0200 (CEST)
Michael Van Canneyt [EMAIL PROTECTED] wrote:

[...]
  Why is the local variable block needed?
 
 It is not. I asked the same question. It was added for symmetry
 reasons: if a local type block is allowed, then a var block should
 also be allowed.
 
 But they are not different from local fields.

Strange. ok.

What local types are/will be allowed?

For example, this is currently not allowed:

  generic TTreeT = class(TObject)
  type public 
TTreeNode = specialize TNodeT;
  end;

And this neither:

  generic TTreeT = class(TObject)
  type public
TTreeNode = class
  Data: T;
end;
  end;


OTOH records and pointers are allowed.
Will this stay, or is this just not yet implemented?


Mattias
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] generics

[Vincent Snijders]

Michael Schnell schreef:

No. Generics are more like using a macro when defining a type.

So a := copies the memory and not a pointer and they are passed by 
value into a procedure.





I think you cut too much context. To which question does this give an answer?

Vincent
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] generics

[Michael Schnell]

Michael Schnell schreef:

No. Generics are more like using a macro when defining a type.

So a := copies the memory and not a pointer and they are passed by 
value into a procedure.





I think you cut too much context. To which question does this give an 
answer?
(Don't you see the link to the message I answered to in the message tree 
with your Newsgroup viewer ?)


The question was:
 Aren't those automatically dynamic?
So the answer is no, as they are not pointers (like instances of Classes).

-Michael

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] generics

[Daniël Mantione]

Op Wed, 20 Dec 2006, schreef Vincent Snijders:

 Will fpc support generic record declarations like this:
 
 type
   generic TFixedKeyNodeKeySize = record
 key: array[0..KeySize-1] of char;
 value: dword;
 end;
 
 In other word the type is not parameterized by another type but by an integer
 used to define the upper limit of an array.

Basically, isn't this similar to a schema type like you have in Extended Pascal?

Daniël___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] generics

[Vincent Snijders]

Daniël Mantione schreef:


Op Wed, 20 Dec 2006, schreef Vincent Snijders:


Will fpc support generic record declarations like this:

type
  generic TFixedKeyNodeKeySize = record
key: array[0..KeySize-1] of char;
value: dword;
end;

In other word the type is not parameterized by another type but by an integer
used to define the upper limit of an array.


Basically, isn't this similar to a schema type like you have in Extended Pascal?


No idea. I have absolutely no knowledge about Extended Pascal. Can you give a link 
which describes that?


Vincent
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] generics

[Michael Schnell]

Will fpc support generic record declarations like this:

type
  generic TFixedKeyNodeKeySize = record
key: array[0..KeySize-1] of char;
value: dword;
  end;

In other word the type is not parameterized by another type but by an 
integer used to define the upper limit of an array.


Free Pascal seems to support macros (I did not try yet): 
http://www.freepascal.org/docs-html/prog/progse5.html


With this compile-time variable typedefs should be doable.

-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] generics

[Daniël Mantione]

Op Wed, 20 Dec 2006, schreef Vincent Snijders:

 Daniël Mantione schreef:
  
  Op Wed, 20 Dec 2006, schreef Vincent Snijders:
  
   Will fpc support generic record declarations like this:
   
   type
generic TFixedKeyNodeKeySize = record
   key: array[0..KeySize-1] of char;
   value: dword;
   end;
   
   In other word the type is not parameterized by another type but by an
   integer
   used to define the upper limit of an array.
  
  Basically, isn't this similar to a schema type like you have in Extended
  Pascal?
 
 No idea. I have absolutely no knowledge about Extended Pascal. Can you give a
 link which describes that?

http://www.gnu-pascal.de/gpc/Schema-Types.html

Daniël___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] generics

[Marco van de Voort]

 Op Wed, 20 Dec 2006, schreef Vincent Snijders:
 
  
  In other word the type is not parameterized by another type but by an 
  integer
  used to define the upper limit of an array.
 
 Basically, isn't this similar to a schema type like you have in Extended
 Pascal?

Aren't those automatically dynamic?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] generics

[Daniël Mantione]

Op Wed, 20 Dec 2006, schreef Marco van de Voort:

  Op Wed, 20 Dec 2006, schreef Vincent Snijders:
  
   
   In other word the type is not parameterized by another type but by an 
   integer
   used to define the upper limit of an array.
  
  Basically, isn't this similar to a schema type like you have in Extended
  Pascal?
 
 Aren't those automatically dynamic?

What do you mean with dynamic? Dynamic memory management: no, static.

Daniël___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] generics

[Marco van de Voort]

 Op Wed, 20 Dec 2006, schreef Marco van de Voort:
In other word the type is not parameterized by another type but by an 
integer
used to define the upper limit of an array.
   
   Basically, isn't this similar to a schema type like you have in Extended
   Pascal?
  
  Aren't those automatically dynamic?
 
 What do you mean with dynamic? Dynamic memory management: no, static.

Yes, that is what I meant. So just to be clear: you can create a schema type
on the stack? Or nest it inside a record, and it remains a single record?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] generics

[Daniël Mantione]

Op Wed, 20 Dec 2006, schreef Marco van de Voort:

  Op Wed, 20 Dec 2006, schreef Marco van de Voort:
 In other word the type is not parameterized by another type but by an 
 integer
 used to define the upper limit of an array.

Basically, isn't this similar to a schema type like you have in Extended
Pascal?
   
   Aren't those automatically dynamic?
  
  What do you mean with dynamic? Dynamic memory management: no, static.
 
 Yes, that is what I meant. So just to be clear: you can create a schema type
 on the stack? Or nest it inside a record, and it remains a single record?

Yes, confirmed, and if you blockwrite the record (if that is possible in 
GPC), you write the schema to disk.

Daniël___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Jonas Maebe]

On 13 apr 2006, at 00:29, Flávio Etrusco wrote:


http://www.dummzeuch.de/delphi/object_pascal_templates/english.html

http://community.borland.com/article/0,1410,27603,00.html


Ingenious! I really feel stupid for not thinking of something that
simple like this before :-)


Something similar is used in the matrix unit of the rtl (at least for  
the implementation, see rtl/inc/matrix.pp).



Jonas___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Marc Weustink]

Flávio Etrusco wrote:

On 4/12/06, Bisma Jayadi [EMAIL PROTECTED] wrote:


It isn't clear to me what the current status about Generics is:
http://www.freepascal.org/wiki/index.php/Generics


http://www.dummzeuch.de/delphi/object_pascal_templates/english.html

http://community.borland.com/article/0,1410,27603,00.html




Ingenious! I really feel stupid for not thinking of something that
simple like this before :-)


Is it possible this way to derive 2 (or more) classes in one unit from 
the same generic ?


Marc

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Daniël Mantione]

Op Thu, 13 Apr 2006, schreef Marc Weustink:

  Ingenious! I really feel stupid for not thinking of something that
  simple like this before :-)
 
 Is it possible this way to derive 2 (or more) classes in one unit from the
 same generic ?

The matrix unit does it. It uses FPC's preprocessor instead of type 
aliases, though.

Daniël___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Peter Vreman]

 On 4/11/06, Marco van de Voort [EMAIL PROTECTED] wrote:

  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) ;-)

 First, I should have made it more clear that I meant:
 - Templates = C++ templates = macros;
 - Type erasure generics = Java generics = the template has an
 equivalent _single_ class, for which templates parameters are resolved
 by normal OO, and each template instance (e.g. TListTItemType:
 TComponent) don't generate any additional code, the instance types
 are only know at compile-time and checked and exposed for external
 code.

 To summaryze yeat more:
 Generics are much simpler to use and to implement, I'm afraid poeple
 will overuse (and use badly) template flexibitlity, and there's no way
 to implement 'properties' without getter methods when using type
 erasure through templates.

The short answer on everything you say: Forget Java generics.

FPC is a compiled language where not all types are classes. The only way
to implement it is like C++ templates. It is a known fact that generics
will introduce code bloat, but that is still less than the 15-20mb virtual
machines you need for Java/C#



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Danny Milosavljevic]

Hi,

Am Dienstag, den 11.04.2006, 18:56 -0300 schrieb Flávio Etrusco:
 On 4/11/06, Danny Milosavljevic [EMAIL PROTECTED] wrote:
  Hi,
 
  Am Montag, den 10.04.2006, 23:33 -0300 schrieb Flávio Etrusco:
   On 4/10/06, Danny Milosavljevic [EMAIL PROTECTED] 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)
 
 Do you honestly have any use for generics supporting primitive types
 other than writing half a dozen containers?

Probably not, because my main use is containers. I cringe when I have
TStringList but no TIntegerList, for example... (and all the others)

 
  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...
 
 You can't be serious. Why do you need containers or whatever code so
 specific and optimized for all these types? 

In order for it not to be slow :)

 And do you wanna count
 many TObject descendants vs. native types (including records) does the
 e.g. FCL include?

There are many... 
but not all of them will have a specialization automatically from the
start, only on use.

 
 
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)
 
 Why do the String in this case need to be anything other than a String?

I don't understand... string is a primitive type, so it wouldn't work in
this example, no?

 
 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'm talking about debbuging, so besides gcc, gdb and some other user
 interface must be working pretty well too; what are they?
 I know that VisualStudio 2003 certainly isn't (I didn't try VS 2005
 yet, but I doubt it is any better is this respect...).

Good question...

 
   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...
 
 If this was the case of course I would have be glad :-) I'd still be
 afraid to have FCL becoming anything like the STL (i.e. as horrible
 and impossible to read as it), though...
 
 Following the URL Micha sent in a previous reply, I've just read that
 .net 2 supports generics for native type by recompiling the templates
 only in this case. Interesting...
 http://cakoose.com/wiki/microsoft_clr


yeah, nice :)

cheers,
  Danny


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Bisma Jayadi]

It isn't clear to me what the current status about Generics is:
http://www.freepascal.org/wiki/index.php/Generics


http://www.dummzeuch.de/delphi/object_pascal_templates/english.html

http://community.borland.com/article/0,1410,27603,00.html

-Bee-

has Bee.ography at
http://beeography.wordpress.com
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Micha Nelissen]

On Wed, 12 Apr 2006 08:31:58 +0200 (CEST)
Peter Vreman [EMAIL PROTECTED] wrote:

 FPC is a compiled language where not all types are classes. The only way
 to implement it is like C++ templates. It is a known fact that generics
 will introduce code bloat, but that is still less than the 15-20mb virtual
 machines you need for Java/C#

Those 'bloat's are not really comparable because they have a different
origin. 

With templates you can prevent bloat by designing/implementing your data
structure with a size parameter, then the generic descendent will only be a
bunch of inlined typecasts - no bloat. Of course, the generic size
parameter may waste memory and/or CPU cycles, but that's exactly where the
tradeoff has to be made anyway.

Micha
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Flávio Etrusco]

On 4/12/06, Bisma Jayadi [EMAIL PROTECTED] wrote:
  It isn't clear to me what the current status about Generics is:
  http://www.freepascal.org/wiki/index.php/Generics

 http://www.dummzeuch.de/delphi/object_pascal_templates/english.html

 http://community.borland.com/article/0,1410,27603,00.html


Ingenious! I really feel stupid for not thinking of something that
simple like this before :-)

Cheers,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Micha Nelissen]

On Tue, 11 Apr 2006 13:06:27 -0300
Flávio Etrusco [EMAIL PROTECTED] wrote:

  What does type erasure mean without a runtime engine (VM) ?
 
 That the template is not aware of the instantiated type of the
 template parameters, they are only accessed/resolved through oop
 (inheritance/polymorphism).

That's bad. Why not use interfaces instead, then ?

 A VM isn't necessary at all; for instance, J2SE 5 didn't introduce any
 modification in the VM (for supporting generics or anything), and most
 of the compiler changes were only needed because of the Java object
 model.

Yes, that's why generics in Java suck ;-). At least, according to (first
google hit for type erasure):

http://cakoose.com/wiki/type_erasure_is_not_evil

Micha
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Flávio Etrusco]

On 4/11/06, Marco van de Voort [EMAIL PROTECTED] wrote:

  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) ;-)

First, I should have made it more clear that I meant:
- Templates = C++ templates = macros;
- Type erasure generics = Java generics = the template has an
equivalent _single_ class, for which templates parameters are resolved
by normal OO, and each template instance (e.g. TListTItemType:
TComponent) don't generate any additional code, the instance types
are only know at compile-time and checked and exposed for external
code.

To summaryze yeat more:
Generics are much simpler to use and to implement, I'm afraid poeple
will overuse (and use badly) template flexibitlity, and there's no way
to implement 'properties' without getter methods when using type
erasure through templates.

 What I don't understand is all these differences between templates and
 generics while the only difference is that for classes you do type erasure.

 Note that for reference types you can also do type erasure under FPC _AND_
 classes are always reference types.

Can you please be more specific? English is not my native language and
I'm having some trouble to understand what you meant.

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Flávio Etrusco]

On 4/11/06, Danny Milosavljevic [EMAIL PROTECTED] wrote:
 Hi,

 Am Montag, den 10.04.2006, 23:33 -0300 schrieb Flávio Etrusco:
  On 4/10/06, Danny Milosavljevic [EMAIL PROTECTED] 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)

Do you honestly have any use for generics supporting primitive types
other than writing half a dozen containers?

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

You can't be serious. Why do you need containers or whatever code so
specific and optimized for all these types? And do you wanna count
many TObject descendants vs. native types (including records) does the
e.g. FCL include?


   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)

Why do the String in this case need to be anything other than a String?

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'm talking about debbuging, so besides gcc, gdb and some other user
interface must be working pretty well too; what are they?
I know that VisualStudio 2003 certainly isn't (I didn't try VS 2005
yet, but I doubt it is any better is this respect...).

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

If this was the case of course I would have be glad :-) I'd still be
afraid to have FCL becoming anything like the STL (i.e. as horrible
and impossible to read as it), though...

Following the URL Micha sent in a previous reply, I've just read that
.net 2 supports generics for native type by recompiling the templates
only in this case. Interesting...
http://cakoose.com/wiki/microsoft_clr

Cheers,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Marco van de Voort]

   What compiler? If gcc, gcc does nothing fast, and C++ header model than 
   the
   bit of codegenerating done.
 
  nothing fast ..., _the problem is more_ ... C++ header model
 
 VisualC++ 6.
 I know it's much related to C header model and linking, but I never
 saw any complete research about how much these affect the problem,
 and I'm afraid some of the problems can't just be avoided

But easily avoided with Pascal with its thorough precompiled system. 
 
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Danny Milosavljevic]

Hi,

Am Sonntag, den 09.04.2006, 18:51 -0300 schrieb Flávio Etrusco:
 I hope I'm not being too annoying, I'm just trying to understand
 better your decision/opinion. If you think this discussion is useless
 please speak and I'll shut up ;-)
 
  Well, talking about Java's speed never makes sense.
 
 LOL, I agree :-)
 
  Fact is, if you use
  classes that you've always an indirection because of the pointer and
  extra memory manager overhead while for simple tasks you can use simple
  embed the data into the container data when using real templates.
 
 I know, and using type erasure will even frequently force the use of
 inheritance (virtual/dynamic methods) that will add a little more
 overhead, 


 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 :)


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

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

 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?

 so I still fail to see where generic for non-objects
 would be a big loss.

It is.

 
   I guess I was a bit too hasty on the whining, but just thinking about
   C++ compilation speed when using templates give me cries...
 
  This has nothing to do with templates.
 
 I've read the opposite many times, but I know that it's much related
 to C++ pre-processor, headers and linking models, and -again- I'm no
 C++ or compilers expert. If you say it won't be an issue in FPC, I'm
 happier then :-)
 
 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.

 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 :)

 
 Cheers,
 Flávio

cheers,
  Danny


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Flávio Etrusco]

On 4/10/06, Danny Milosavljevic [EMAIL PROTECTED] 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.

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

 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.

  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.

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

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?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Florian Klaempfl]

[EMAIL PROTECTED] wrote:
 It isn't clear to me what the current status about Generics is:
 http://www.freepascal.org/wiki/index.php/Generics

2.1.1 contains pre alpha code, they aren't usable yet.. It is subject to
be finished with 2.2.

 Are they Delphi conform 

Is there already a specification how they will look like in Delphi?

 (.net2)? What's planned? Can somebody explain?


They are more like C++ templates.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[rstar]

Florian Klaempfl wrote:

Is there already a specification how they will look like in Delphi?
  
I think no. But there is already a specification for C#. I guess the 
Delphi syntax won't be differ to much from the C# definition:

http://qc.borland.com/wc/qcmain.aspx?d=11168
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Flávio Etrusco]

On 4/9/06, Florian Klaempfl [EMAIL PROTECTED] wrote:
 [EMAIL PROTECTED] wrote:
 (...)
 Is there already a specification how they will look like in Delphi?

  (.net2)? What's planned? Can somebody explain?
 

 They are more like C++ templates.

What? Do you mean that FPC implementation of generics wouldn't be
based on type erasure but on beefed-up-precompiler-macros? Please
say I got it all wrong :-o

-Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Marco van de Voort]

 What? Do you mean that FPC implementation of generics wouldn't be
 based on type erasure but on beefed-up-precompiler-macros? Please
 say I got it all wrong :-o

Do you have documents about type erasure in native languages where e.g. a
string is not an object ?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[rstar]

Flávio Etrusco wrote:

On 4/9/06, Florian Klaempfl [EMAIL PROTECTED] wrote:
  

[EMAIL PROTECTED] wrote:
(...)
Is there already a specification how they will look like in Delphi?



(.net2)? What's planned? Can somebody explain?

  

They are more like C++ templates.



What? Do you mean that FPC implementation of generics wouldn't be
based on type erasure but on beefed-up-precompiler-macros? Please
say I got it all wrong :-o

-Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


  

Generics are type safe.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Florian Klaempfl]

Flávio Etrusco wrote:
 On 4/9/06, Florian Klaempfl [EMAIL PROTECTED] wrote:
 [EMAIL PROTECTED] wrote:
 (...)
 Is there already a specification how they will look like in Delphi?

 (.net2)? What's planned? Can somebody explain?

 They are more like C++ templates.
 
 What? Do you mean that FPC implementation of generics wouldn't be
 based on type erasure but on beefed-up-precompiler-macros? Please
 say I got it all wrong :-o

You want crippled generics regarding speed and usage like C# has? You
can do this with real templates as well using an implementation class
and wrapper templates.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Flávio Etrusco]

On 4/9/06, Marco van de Voort [EMAIL PROTECTED] wrote:
  What? Do you mean that FPC implementation of generics wouldn't be
  based on type erasure but on beefed-up-precompiler-macros? Please
  say I got it all wrong :-o

 Do you have documents about type erasure in native languages where e.g. a
 string is not an object ?

You have a point. But I don't think supporting generics for native
types is a must-have. The syntatic sugar for having typesafe
containers and algorithms for _objects_ is all I wanted ;-)

Cheers,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Florian Klaempfl]

Flávio Etrusco wrote:
 On 4/9/06, Marco van de Voort [EMAIL PROTECTED] wrote:
 What? Do you mean that FPC implementation of generics wouldn't be
 based on type erasure but on beefed-up-precompiler-macros? Please
 say I got it all wrong :-o
 Do you have documents about type erasure in native languages where e.g. a
 string is not an object ?
 
 You have a point. But I don't think supporting generics for native
 types is a must-have. The syntatic sugar for having typesafe
 containers and algorithms for _objects_ is all I wanted ;-)

Well, that's you :) Other people want different things :)
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Marco van de Voort]

 On 4/9/06, Marco van de Voort [EMAIL PROTECTED] wrote:
   What? Do you mean that FPC implementation of generics wouldn't be
   based on type erasure but on beefed-up-precompiler-macros? Please
   say I got it all wrong :-o
 
  Do you have documents about type erasure in native languages where e.g. a
  string is not an object ?
 
 You have a point. But I don't think supporting generics for native
 types is a must-have. The syntatic sugar for having typesafe
 containers and algorithms for _objects_ is all I wanted ;-)

First attempt at a string,object map would already fail. No thanks, too
limited.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Flávio Etrusco]

On 4/9/06, Florian Klaempfl [EMAIL PROTECTED] wrote:
 Flávio Etrusco wrote:
  On 4/9/06, Florian Klaempfl [EMAIL PROTECTED] wrote:
  [EMAIL PROTECTED] wrote:
  (...)
  Is there already a specification how they will look like in Delphi?
 
  (.net2)? What's planned? Can somebody explain?
 
  They are more like C++ templates.
 
  What? Do you mean that FPC implementation of generics wouldn't be
  based on type erasure but on beefed-up-precompiler-macros? Please
  say I got it all wrong :-o

 You want crippled generics regarding speed and usage like C# has? You
 can do this with real templates as well using an implementation class
 and wrapper templates.

I've never heard any critics/complaints on the performance of generics
in Java (I'm not much into .net 2 yet), but you certainly know better
than me.
I guess I was a bit too hasty on the whining, but just thinking about
C++ compilation speed when using templates give me cries... TBH I
never tried using type erasure in C++ templates, but I remember C++
templates' inner workings to have enough pitfalls for me to want to
avoid templates at all costs...


Cheers,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Marco van de Voort]

   What? Do you mean that FPC implementation of generics wouldn't be
   based on type erasure but on beefed-up-precompiler-macros? Please
   say I got it all wrong :-o
 
  You want crippled generics regarding speed and usage like C# has? You
  can do this with real templates as well using an implementation class
  and wrapper templates.
 
 I've never heard any critics/complaints on the performance of generics
 in Java (I'm not much into .net 2 yet), but you certainly know better
 than me.

 I guess I was a bit too hasty on the whining, but just thinking about
 C++ compilation speed

What compiler? If gcc, gcc does nothing fast, and C++ header model than the
bit of codegenerating done.

 when using templates give me cries... TBH I
 never tried using type erasure in C++ templates, but I remember C++
 templates' inner workings to have enough pitfalls for me to want to
 avoid templates at all costs...

The Type erasure in Java5 is also known to have pitfalls. E.g. check the
site of http://www.angelikalanger.com or just throw type erasure in
google.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Florian Klaempfl]

Flávio Etrusco wrote:
 On 4/9/06, Florian Klaempfl [EMAIL PROTECTED] wrote:
 Flávio Etrusco wrote:
 On 4/9/06, Florian Klaempfl [EMAIL PROTECTED] wrote:
 [EMAIL PROTECTED] wrote:
 (...)
 Is there already a specification how they will look like in Delphi?

 (.net2)? What's planned? Can somebody explain?

 They are more like C++ templates.
 What? Do you mean that FPC implementation of generics wouldn't be
 based on type erasure but on beefed-up-precompiler-macros? Please
 say I got it all wrong :-o
 You want crippled generics regarding speed and usage like C# has? You
 can do this with real templates as well using an implementation class
 and wrapper templates.
 
 I've never heard any critics/complaints on the performance of generics
 in Java (I'm not much into .net 2 yet), but you certainly know better
 than me.

Well, talking about Java's speed never makes sense. Fact is, if you use
classes that you've always an indirection because of the pointer and
extra memory manager overhead while for simple tasks you can use simple
embed the data into the container data when using real templates.

 I guess I was a bit too hasty on the whining, but just thinking about
 C++ compilation speed when using templates give me cries... 

This has nothing to do with templates.

 TBH I
 never tried using type erasure in C++ templates, but I remember C++
 templates' inner workings to have enough pitfalls for me to want to
 avoid templates at all costs...
 
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Marco van de Voort]

  I guess I was a bit too hasty on the whining, but just thinking about
  C++ compilation speed
 
 What compiler? If gcc, gcc does nothing fast, and C++ header model than the
 bit of codegenerating done.

nothing fast ..., _the problem is more_ ... C++ header model
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Flávio Etrusco]

I hope I'm not being too annoying, I'm just trying to understand
better your decision/opinion. If you think this discussion is useless
please speak and I'll shut up ;-)

 Well, talking about Java's speed never makes sense.

LOL, I agree :-)

 Fact is, if you use
 classes that you've always an indirection because of the pointer and
 extra memory manager overhead while for simple tasks you can use simple
 embed the data into the container data when using real templates.

I know, and using type erasure will even frequently force the use of
inheritance (virtual/dynamic methods) that will add a little more
overhead, but thing is I can't see much use for generics for low level
tasks.
There are relatively few native types that is usually ok duplicate the
whole code if it need be. And it seems to me that absolutely most of
the times we are working with classes instead of just single primitive
variables, so I still fail to see where generic for non-objects
would be a big loss.

  I guess I was a bit too hasty on the whining, but just thinking about
  C++ compilation speed when using templates give me cries...

 This has nothing to do with templates.

I've read the opposite many times, but I know that it's much related
to C++ pre-processor, headers and linking models, and -again- I'm no
C++ or compilers expert. If you say it won't be an issue in FPC, I'm
happier then :-)

However, I'm still worried about the bloat that templates tend to add
to the binary/executable 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)...

Cheers,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics

[Flávio Etrusco]

On 4/9/06, Marco van de Voort [EMAIL PROTECTED] wrote:
   I guess I was a bit too hasty on the whining, but just thinking about
   C++ compilation speed
 
  What compiler? If gcc, gcc does nothing fast, and C++ header model than the
  bit of codegenerating done.

 nothing fast ..., _the problem is more_ ... C++ header model

VisualC++ 6.
I know it's much related to C header model and linking, but I never
saw any complete research about how much these affect the problem,
and I'm afraid some of the problems can't just be avoided

 The Type erasure in Java5 is also known to have pitfalls. E.g. check the
 site of http://www.angelikalanger.com or just throw type erasure in
 google.

Thanks, I'll read it right now :-)

Cheers,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics Basics

[Jonas Maebe]

On 11 Nov 2005, at 08:50, Micha Nelissen wrote:


What is late binding exactly ? What are you binding ?


Late binding means that the compiler doesn't have to be able to  
figure out at compile time whether or not a particular object  
understands a particular message (aka has a method with a particular  
name), or where this message is located in the VMT (so if you have  
two independent class hierarchies which implement method FOO, you can  
still use obj.foo() and get the correct method called in both cases).


In case the compiler knows the type, the implementation is the same  
as with regular OOP languages. If it doesn't, then the method call  
happens via some kind of hashtable lookup with caching.



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics Basics

[dannym]

Hi,

Am Donnerstag, den 10.11.2005, 20:24 +1100 schrieb John Briggs:
 On Tue, Nov 08, 2005 at 10:00:49PM +0100, dannym wrote:
  Hi,
  
  Am Dienstag, den 08.11.2005, 18:10 -0200 schrieb Felipe Monteiro de
  Carvalho:
   Hello,
   
   I am trying to understand what exactly generics are. I read the wiki
   page, but there are lot's of code examples and very few explanations.
   Can someone explain it to me in a (relatively) simple way?
   
   What problem is it trying to solve?
  
  It makes types parametrizable.
  
 Just my two cents worth:
 
 To me generics should essentially make FPC a typeless language. 

no, more typesafe, rather.

 i.e. everthing
 is an object and you just pass messages between objects, ala Smalltalk. 

No

 How it
 is implemented is a moot point because at the top level you shouldn't be able 
 to see the implementation of the objects.

Depends on what you mean by see

 
 The one thing that does concern me is why implement generics if you fail to 
 implement the late binding of the objects which to me is the greatest gain of
 generic programming.

Can you explain that some more?

 
 Feel free to shoot me down in flames as I have not been following this
 discussion fully to understand all of its details
 
 John

cheers,
   Danny


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics Basics

[John Briggs]

On Tue, Nov 08, 2005 at 10:00:49PM +0100, dannym wrote:
 Hi,
 
 Am Dienstag, den 08.11.2005, 18:10 -0200 schrieb Felipe Monteiro de
 Carvalho:
  Hello,
  
  I am trying to understand what exactly generics are. I read the wiki
  page, but there are lot's of code examples and very few explanations.
  Can someone explain it to me in a (relatively) simple way?
  
  What problem is it trying to solve?
 
 It makes types parametrizable.
 
Just my two cents worth:

To me generics should essentially make FPC a typeless language. i.e. everthing
is an object and you just pass messages between objects, ala Smalltalk. How it
is implemented is a moot point because at the top level you shouldn't be able 
to see the implementation of the objects.

The one thing that does concern me is why implement generics if you fail to 
implement the late binding of the objects which to me is the greatest gain of
generic programming.

Feel free to shoot me down in flames as I have not been following this
discussion fully to understand all of its details

John
-- 
Feeling exploited, impoverished or imprisoned??
Knock down the Gates of  and break free into the Brave GNU World of the
Free Software Foundation.
Squeak with delight at pleasure this freedom brings.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel