[fpc-devel] generics with type-identifier "object" - documented yes, but ...?

[Martin Frb via fpc-devel]

According to  https://www.freepascal.org/docs-html/ref/refse53.html
the keyword "object" is allowed as a "type identifier" for identifiers 
in the "template list" of a generic definition.


Yet, the below does not compile (tested with 3.2.0 / 3.2.2 / 3.2.3 and 
3.3.1 from 2022-Feb-10)


program Project1; {$mode objfpc}{$H+}
type
  generic TFoo = class   end;

Neither does this work (only tested 3.2.3)
type
  TX = object end;
  generic TFoo = class end;

Whereas each of the below does work fine:
  generic TFoo = class   end;
  generic TFoo = class   end;
  generic TFoo = class   end;

The same applies for: "generic TFoo = record end;". So the type 
of the generic itself seems not to affect this.



Similar, the doc says that the keyword "interface" is allowed, but this 
does not work:

  generic TFoo = class   end;
However using IInterface (or any declared interface type) does work
  generic TFoo = class   end;



As a side note, the diagram for "identifier list" on the above doc page, 
seems to indicate that the "type identifier" after the colon can be a 
comma separated list.

Is that meant to be like that?
___
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]

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

[fpc-devel] Generics-related compilation issue

[Werner Pamler via fpc-devel]

A happy, successful and healthy New Year to everybody!

I have a generics related compilation issue in my package ExCtrls 
package 
(https://sourceforge.net/p/lazarus-ccr/svn/HEAD/tree/components/exctrls/). 
This package contains a TCurrencySpinEditEx component which inherits 
from the TSpinEditExBase component of the LazControls package coming 
with Lazarus. TSpinEditExBase introduces generic fields FValue, 
FIncrement, FMaxValue etc, and each decendent of it specializes these 
types, i.e. in TCustomFloatSpinEditEx FValue, FIncrement, FMaxValue are 
double, and in the CurrencySpinEdit for the ExCtrls package they are 
currency values.


The compilation of the ExCtrls package fails for example in the 
IncrementStored method of TSpinEditExBase


    function TSpinEditExBase.IncrementStored: Boolean;
    begin
      Result := not SameValue(FIncrement, DefIncrement);   // <--- 
error here; SameValue is from unit Math

    end;

the error message says: "Can't determine which overloaded function to 
call". FIncrement and DefIncrement are generic types here.


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)


I can solve the compilation issue by moving the IncrementStored method 
into the derived classes. But this kind of contradicts the idea with 
using generic types in the first place.


Is there another way to solve this issue?

Werner


___
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

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

[Martok]

Hi everyone,

I had already reported the issue as
, but as this problem is currently
blocking a clean solution in a project for us, I'm asking for help again here.

The problem appears to be that when a generic uses its type parameter to
inline-specialize another generic (ie. inherit from it), that generic cannot be
specialized anywhere else (ie. return value of that type) or a name collision
occurs. Not really sure why that happens, but for some reason the compiler
doesn't recognize that the two instances don't have the same name by accident
but really are the same type.

Do you have any idea what could be done to work around this?

Thank you in advance,

Martok

___
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

[fpc-devel] Generics collections

[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

Re: [fpc-devel] generics and scoping rules

[Sven Barth]

Am 08.05.2015 23:56 schrieb "Martin Frb" :
>
> 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 TLazGenStorageMem = 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

[fpc-devel] generics and scoping rules

[Martin Frb]

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 TLazGenStorageMem = 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?
___
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:

   TSomeObject = Class;
   TSomeOtherObject = Class(TSomeObject );

And finally:

   TMyObject = Class;
   TSomeOtherOtherObject = Class(TSomeOtherObject );

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
  TSomeObject = Class
  end;

  TSomeOtherObject = Class(TSomeObject );

  TMyObject = Class
  end;

  TSomeOtherOtherObject = Class(TSomeOtherObject );

=== 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 
TSomeObject).


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:

   TSomeObject = Class;
   TSomeOtherObject = Class(TSomeObject );

And finally:

   TMyObject = Class;
   TSomeOtherOtherObject = Class(TSomeOtherObject );

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
  TSomeObject = Class
  end;

  TSomeOtherObject = Class(TSomeObject );

  TMyObject = Class
  end;

  TSomeOtherOtherObject = Class(TSomeOtherObject );

=== 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 
TSomeObject).


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] Generics, TObject Descendant?

[Den]

Hi there,

Currently this code:

  TSomeObject = Class;
  TSomeOtherObject = Class(TSomeObject );

And finally:

  TMyObject = Class;
  TSomeOtherOtherObject = Class(TSomeOtherObject );

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


- Dennis
___
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

[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

[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

TDelegateImpl = class(TInterfacedObject, IDelegate)

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]

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

TDelegateImpl = class(TInterfacedObject, IDelegate)

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.

On Fri, May 11, 2012 at 4:17 PM, Sven Barth wrote:

> 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 TDictionary =
>> class(TEnumerable>) ...
>>
>
> 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
>
___
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 TDictionary =
class(TEnumerable>) ...


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 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 TDictionary =
class(TEnumerable>) ...

Given:

type
  TCollection = class
  end;

  TPair = class
Key: K;
Value: V;
  end;

// Test

var
  TestA: TCollection>; // Fatal: Syntax error, ","
expected but "<" found
  TestB: TCollection; // Okay

The same problem occurs with classes

type
  TDictionaryA = class(TCollection>)  // Fatal: Syntax
error, "," expected but "<" found
  end;
  TDictionaryB = class(TCollection)  // 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

[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, 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

[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}
> 
> { TEnumerator }
> 
> type
>   TEnumerator = class abstract
>   protected
> function DoGetCurrent: T; virtual; abstract;
> function DoMoveNext: Boolean; virtual; abstract;
>   public
> property Current: T read DoGetCurrent;
> function MoveNext: Boolean;
>   end;
> 
> { TEnumerable }
> 
>   TEnumerable = class abstract
>   protected
> function DoGetEnumerator: TEnumerator; virtual; abstract; //
> Error: Generics without specialization cannot be used as a type for a
> variable
>   public
> function GetEnumerator: TEnumerator;
>   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

[fpc-devel] Generics are still broken

[Anthony Walter]

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}

{ TEnumerator }

type
  TEnumerator = class abstract
  protected
function DoGetCurrent: T; virtual; abstract;
function DoMoveNext: Boolean; virtual; abstract;
  public
property Current: T read DoGetCurrent;
function MoveNext: Boolean;
  end;

{ TEnumerable }

  TEnumerable = class abstract
  protected
function DoGetEnumerator: TEnumerator; virtual; abstract; // Error:
Generics without specialization cannot be used as a type for a variable
  public
function GetEnumerator: TEnumerator;
  end;
___
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 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 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 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 - 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

[fpc-devel] Generics - a general question

[AvP]

I just made a first attempt to use generics. Trying different things I figured
out that the appended code compiles without any error message in FPC
2.6.0RC1

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

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

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.

Maybe I'm trying to do the manager in a way, that isn't the right one - other
suggestions are welcome - but as this is on a developer maillist (I
know), my question mainly concerns the general generics part.

Thanks
A.v.P.


program Test;

{$mode objfpc}{$H+}

uses Classes;

{$R *.res}

type

 TType = object
 RefCount : Word;
 constructor Init;
 destructor Done;
 function GetCount : Word;
 end;

 // manages a list of _ResType-Objects
 generic TManager<_ResType> = object  //(1)
   // _ResType must be TType or detrieved, howto define this??
   type
 PResType = ^_ResType;
   public
 constructor Create;
 destructor Destroy;
 function GetRefCount : Word;
 // stuff to manage Resource-array
   private
 Resource : array of PResType;   // array of pointer to specialized type
of generic
 end;

 TResManager = specialize TManager;

 constructor TType.Init;
 begin
   RefCount := 3;
   WriteLn('TType.Init done...');
 end;

 destructor TType.Done;
 begin
   WriteLn('TType.Done...');
 end;

 function TType.GetCount : Word;
 begin
   Result := Self.RefCount;
 end;



 constructor TManager.Create;
 begin
   SetLength(Resource, 2);
   Resource[0]^.Init;  // No problem here
   WriteLn('Manager.Create done...');
 end;

 destructor TManager.Destroy;
 begin
   Resource[0]^.Done;  // No problem here
   WriteLn('Manager.Destroy done...');
 end;

 function TManager.GetRefCount : Word;
 begin
   Result := Resource[0]^.RefCount;  // direct access
   // or:
   //Result := Resource[0]^.GetCount;// helper function
 end;

Var
 TT : TResManager;
begin
 TT.Create;
 WriteLn(TT.GetRefCount);
// if commented then 'no problem' else 'Access violation' 
 TT.Destroy;
end.



An unhandled exception occurred at $00411D90 :
EAccessViolation : Access violation
 $00411D90 line 66 of Test.lpr
 $00411DF6 line 76 of Test.lpr
___
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

[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 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]

On Mon, Aug 29, 2011 at 11:19 AM, Sven Barth wrote:

> 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 = foo") 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.
> foo =... foo  = ...); 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]

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 = foo") 
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. 
foo =... foo  = ...); 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

[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

[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: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.MyGenericMethod(List: TList);

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]

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

e.g. type TObjectList = class TList ... 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

[Anthony Walter]

On Mon, Aug 29, 2011 at 10:15 AM, Paul Ishenin  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.MyGenericMethod(List: TList);

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

[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

[fpc-devel] Generics in FPC have many problems

[Anthony Walter]

Jump to "So here are some of the problems I've found with fpc generics" if
you don't want to read the backstory.

I haven't been active in the FPC for a while, but last week I was asking
some questions about the upcoming Delphi FireMonkey project which is
supposed to allow broader development with Pascal/Delphi. My first question
to a newsgroup was, what about FPC, is the FireMonkey project going to work
with it? I was redirected to this article:

http://wiki.freepascal.org/FPC_New_Features_Trunk

Great, these were the new features I was looking for, bridging Delphi and
FPC {$mode delphi} features. So then last week I switched my laptop windows
SSD for my linux SSD and got the latest sources of FPC and Lazarus sources.
I wrote a new XML wrapper around both libxml and msxml, and then dove into
converting my Delphi generics library. My eventual goal is to create the
best cross platform game engine ever based on Delphi/Pascal.

I filled out a few bugs on the issue tracker for Lazarus where the new
generic syntax for  {$mode delphi} broke CodeTools. Then sent a few patches
to fix those issues myself (yeah me).

But then on Saturday I started out porting my generics library, and quickly
began to fall into depression. It seems FPC have a lot of problems with
generics. I had to take a break from all my language testing due to all the
problems I kept running into which made my head spin after each session of
tryng to figure out what the problems are.

On Sunday I sat down again and started hashing out how to get by with FPC
generics. In the evening I finally was able to focus in on the core problems
with the way generics work in FPC.

I'd like to contribute to fixing these problems, but honestly I have no idea
how to modify the compiler. I managed to send some patches off for
CodeTools, but believe the compiler is a whole other level that needs gross
amounts of fixings when it comes to generics. Something I'm not capable of.

Jump: So here are some of the problems I've found with fpc generics.

This does not include all the bugs that cause the compiler to act irrational
one moment and a different irrational the next moment. This is simply a list
of the things FPC generics can't do. I mention these rather than the generic
compiler bugs, because IMO if the way generics work aren't changed, it's not
even worth fixing the compiler bugs the existing syntax brings.

You can't write a generic method in a non generic class. The syntax
'TMyForm.ShowContents' is invalid is invalid in both objfpc and delphi
modes. You are forced to define a generic class if you want to use a generic
method.

type
  TStringConverter = function(Item: T): string; // okay delphi mode, in
objfpc this line should begin with generic

  TMyForm = class(TForm)
procedure ShowContents(List: TList; Converter:
TStringConverter);

...

// Having a generic method is not okay
procedure TMyForm.ShowContents(List: TList; Converter:
TStringConverter);
var
  Item: T;
begin
  ListBox.Items.BeginUpdate;
  try
ListBox.Items.Clear;
for Item in List do
  ListBox.Items.Add(Converter(Item));
  finally
ListBox.Items.EndUpdate;
  end;
end;

You can't use generics without specialization.

// This is not okay. Instead you have to specialize TList and
TStringConverter inside TMyTestObject
procedure TMyTestObject.DumpContents(List: TList; Converter:
TStringConverter);
var
  Item: T;
begin
  FStrings.BeginUpdate;
  try
FStrings.Clear;
for Item in List do
  FStrings.Add(Converter(Item));
  finally
FStrings.EndUpdate;
  end;
end;

Specialization leads to problems, as specialized types from one class cannot
be share with another class. Also you cannot use specialization inside an
interface.

  IMyInterface = interface
function GetCurrent: T;
// because of we specialization can't use other generics in an interface
function CurrentString(Converter: TStringConverter): string;
procedure TakeFirst(List: TList);
property Current: T read GetCurrent;
  end;

The solution:

Get rid of the whole specialization concept in fpc. Generics should be able
to be declared at any point using the type or a generic parameter. You
should be able to simply say things like:

type TMyClass = class List: TList; end;

or

type TMyClass = class procedure CountDistinct(List: List); end;

or

type TMyClass = class function Combine(List: List): string; end;

or

type TMyInterface = function MyMethod(List: List;
Converter: TStringConverter): Integer; end;

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

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

[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)? It
seems that last commit regarding generics was r15850 (August, 19th).

Best,
Aleksa
___
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 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

[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 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 TFPGList;

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

[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 TFPGList;
...
cdescreen.pas(29,63) Fatal: Syntax error, ";" expected but ">" found

If I change the line to   TDrawerDelegateList = specialize
TFPGList" 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

[fpc-devel] Generics syntax error

[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 TFPGList;
...
cdescreen.pas(29,63) Fatal: Syntax error, ";" expected but ">" found

If I change the line to   TDrawerDelegateList = specialize
TFPGList" 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,
-- 
Felipe Monteiro de Carvalho
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Generics problem

[Andrew Brunner]

I've just encountered a generics problem and wanted to know if it was
intentional...

uGenerics.pas

generic GObjectList<_T>=class(TList)
private
  FIndex : integer;
private
  function  Get(Index:integer): _T;
  procedure Put(Index:integer; Item:_T);
public
  constructor Create; virtual;
  destructor Destroy; override;
public
  function  Add(Item: _T):integer;
  function  Delete(Item: _T):integer;
  function  IndexOf(Item:_T):integer;
  function  Next:_T;
public
  property  Items[Index: integer]: _T read Get write Put; default;
end;

---

uCoreObjects.pas

TCoreObjects=class;
.
.
.
  GCoreObjects=specialize GObjectList;
  TCoreObjects=class (GCoreObjects)
  private
FLastError : cardinal;
  protected
FRequest   : THTTPRequest;
FResponse  : THTTPResponse;
FServer: TRSRServer;
FManager   : TRSRManager;
FAccounts  : TUserAccounts;
FFat   : TDSFat;
FDomainP   : PDomain; //  Why can't I access this
field in a descendant class
FKeywordsP : PKeywords;
  public
function IndexOf(var NameSpace:string):integer; overload;
  public
function Execute(var Params:TCoreParams; Var RSR:TRSR; var
Keywords:TKeywords):Cardinal; overload;
function Execute(iIndex:integer; var Params:TCoreParams; Var
RSR:TRSR; Var Keywords:TKeywords):Cardinal; overload;
  public
property LastError:Cardinal read FLastError;
  public
constructor Create(aServer:TRSRServer; aManager:TRSRManager;
aDomainP:PDomain; aKeywordsP:PKeywords; aFat:TDSFat;
aAccounts:TUserAccounts; aRequest:THTTPRequest;
aResponse:THTTPResponse); reIntroduce;
destructor Destroy; override;
  end;

---

unit coAdmin.pas

TAdminCore=Class(TCoreObject)
 .
.
.
TAdminCore.MethodName(foo);
begin
  FList.FDomainP<< Does not compile.  For some reason I get
"Error: identifier indents no member "FDomainP"
end;

Descendant classes for TCoreObject that reference a Fleshed out
Generic does not allow me to access protected fields... Is this
intentional? I would like to make the argument that since the classes
are in the same hierarchical level - FPC should resolve the
reference...

I also tried making the FList member public but to no avail... Any thoughts?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] generics with is operator

[darekm]

Hi

I found problem with is operator using with generics
This program is not compile
error is: Class or Object types "TList$LongInt" and "TList$ShortString"
are not related
But I think it should be possible


{$mode objfpc}

type
   generic TList<_T>=class(TObject)
   public
 data : _T;
 procedure Add(item: _T);
   end;

procedure TList.Add(item: _T);
begin
  data:=item;
end;


type
  TMyIntList = specialize TList;
  TMyStringList = specialize TList;




var
  ilist : TMyIntList;
  slist : TMyStringList;
begin
  ilist := TMyIntList.Create;
  slist := TMyStringList.Create;
  if sList is tObject then writeln('slist object') else halt(1);
  if iList is tObject then writeln('ilist is  tobject') else halt(2);
  if ilist is tMyStringList then halt(3) else writeln('iList is no
tMyStringList ');

end.



Darek

___
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

[Alexander Klenin]

On Thu, Oct 22, 2009 at 04:08, David B Copeland
 wrote:
> In what way is Generics not 100%?
>
> Dave Copeland.

For me at least, the gravest problem is a lack of function-level generics.

-- 
Alexander S. Klenin
___
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

[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 basic library

[Peter Vreman]

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

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?


FPC 2.2.0 has alpha quality generics that is not usable in real 
world. Current FPC 2.2.1 and 2.3.1 have beta quality with some known 
issues (see mantis).



Peter

___
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: TGenericList = 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

[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: TGenericList = 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

[fpc-devel] Generics basic library

[Felipe Monteiro de Carvalho]

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: TGenericList = 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

Re: [fpc-devel] Generics

[Bram Kuijvenhoven]

Florian Klaempfl wrote:

Mattias Gaertner schrieb:

For example, this is currently not allowed:

  generic TTree = class(TObject)
  type public TTreeNode = specialize TNode;
  end;

And this neither:

  generic TTree = 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 TNode = class
   type TChildList = TList; // and how about this?
   Data:T;
   Children:TChildList;
 end;

 generic TTree = class
   type TTreeNode = specialize TNode;
   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

[Micha Nelissen]

Mattias Gaertner wrote:

For example, this is currently not allowed:

  generic TTree = class(TObject)
  type public 
TTreeNode = specialize TNode;

  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

[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 TTree = class(TObject)
> > > > >   type public   TTreeNode = specialize TNode;
> > > > >   end;
> > > > >
> > > > > And this neither:
> > > > >
> > > > >   generic TTree = 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

[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 TTree = class(TObject)
> > > >   type public   TTreeNode = specialize TNode;
> > > >   end;
> > > >
> > > > And this neither:
> > > >
> > > >   generic TTree = 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

[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 TTree = class(TObject)
  type public   TTreeNode = specialize TNode;
  end;

And this neither:

  generic TTree = 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:

> 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 TTree = class(TObject)
> >   type public   TTreeNode = specialize TNode;
> >   end;
> > 
> > And this neither:
> > 
> >   generic TTree = 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]

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 TTree = class(TObject)
  type public 
TTreeNode = specialize TNode;

  end;

And this neither:

  generic TTree = 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

[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 TTree = class(TObject)
  type public 
TTreeNode = specialize TNode;
  end;

And this neither:

  generic TTree = 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

[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 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, 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

[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

[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

[Michael Van Canneyt]

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

[fpc-devel] Generics

[Mattias Gaertner]

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.


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

[fpc-devel] Generics and compiler conditions

[ik]

Hello,

I wish to know if there is a predefine macro or compiler directive
that can tell me if there is a support for generics with something
such as:

{$IFDEF USEGENERICS}
...
{$ELSE}
...
{$ENDIF}

Or

{$IF USEGENERICS}
...
{$ELSE}
..
{$ENDIF}


Thanks,

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

[fpc-devel] Generics

[ik]

Hi All,

I'm looking for a guide (for people that have slow learning curves
like me ;)) regarding understanding generics, and the ability to start
using them.


Thanks,

Ido
--
http://ik.homelinux.org/
___
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

[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]

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.


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

[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 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 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 Vincent Snijders:

> Daniël Mantione schreef:
> > 
> > Op Wed, 20 Dec 2006, schreef Vincent Snijders:
> > 
> > > Will fpc support generic record declarations like this:
> > > 
> > > type
> > >  generic TFixedKeyNode = 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

[Michael Schnell]

Will fpc support generic record declarations like this:

type
  generic TFixedKeyNode = 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

[Vincent Snijders]

Daniël Mantione schreef:


Op Wed, 20 Dec 2006, schreef Vincent Snijders:


Will fpc support generic record declarations like this:

type
  generic TFixedKeyNode = 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

[Daniël Mantione]

Op Wed, 20 Dec 2006, schreef Vincent Snijders:

> Will fpc support generic record declarations like this:
> 
> type
>   generic TFixedKeyNode = 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

[fpc-devel] generics

[Vincent Snijders]

Will fpc support generic record declarations like this:

type
  generic TFixedKeyNode = 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.


I am thinking of trying to use generics to implement the hashtable with fixed size 
keys for the k-nucleotide benchmark: 
http://shootout.alioth.debian.org/gp4/benchmark.php?test=knucleotide&lang=all


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

Re: [fpc-devel] Generics

[Vincent Snijders]

Marc Weustink wrote:

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 ?




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


The only requirements when implementing templates this way is that each new 
type should be declared in a separate unit and you should have the sources for 
the generic classes.


So, no.

Of course if you use macros in fpc, you can. See for example the format 
shortstring and ansistring implementations.


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

[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

[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

[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


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


Yup, same respond of mine when first time I read these articles. I never knew 
(think?) that Delphi can do something like this. Maybe it looks like a bit hack, 
but I can live with that, and the most important is: it works like the way I 
wanted. Even C++ compiler does (almost) the same trick. :)


Quote:
Templates are converted by the C++ compiler (actually it is done by the 
preprocessor, but who cares about this difference?) into copies of the template 
code. This means that with each usage of a template the whole code for this 
template will be added to the program again. This could explain why C++ programs 
are that large. ;-) But this and other similarly complex processes are 
definitely the reason why C++ compilers are that slow (Typical compile times for 
a few ten thousand lines of code in Delphi: 5-10 seconds, in C++ several minutes).

-

-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

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

[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

[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