[fpc-devel] Library announcement: Generics.Collections

[Sven Barth]

Am 22.05.2013 21:44, schrieb Maciej Izak:
> Hi Free Pascal community!
>
> I'm pleased to announce the generic library, compatible with Delphi 
> Generics.Collections (almost ;) ).
>
> Homepage
>
> https://code.google.com/p/fpc-generics-collections/
>
> SVN
>
> http://fpc-generics-collections.googlecode.com/svn/trunk/
>
Nice. Now I know where all those bug reports come from :P
>
> I have no knowledge of FPC compiler design, so i need a little help...
>
> First thing : To finish my work I need critical compiler magic 
> functions/feature. At first look mayby there is no sense for this 
> functions
> but during work on Generic library it's necessary:
Are those available in Delphi as well? If not I see no use in them.
>
>   function GetReferenceToValue(Value: T): Pointer; // for string types 
> return @s[1] or nil for empty string for Int32 return @i etc. returns 
> a reference to the value, as
Consider this code:

=== code begin ===

procedure SomeProc(aValue: Int32);
var
   p: Pointer;
begin
    p := GetReferenceToValue(aValue);
end;

=== code end ===

The value stored in "p" will be of no significant use for you to be 
stored in the longterm, because aValue will be located on the stack and 
thus the pointer will no longer be valid once the function exits. This 
will also be the case for strings, arrays, records, etc. No compiler 
magic will change this.
>
> measured by human/programmer
>   function GetValueSize(Value: T): Integer; // for string types return 
> Length(s), for Int32 returs 4 etc.
You should not store the string's content, but only the reference to the 
string. If you use assignment operators the RTL will take care of the rest.
> Second thing: Bugs. Look at Critical - fix is needed to perform 
> compatibility with Delphi and proper work.
>
> http://bugs.freepascal.org/view.php?id=24283 (CRITICAL! Very Important!)
I don't consider nested specializations as critical. It's likely that I 
will fix this after I've fixed other generic problems...
> http://bugs.freepascal.org/view.php?id=24282 (CRITICAL! Very Important!)
The underlying problem is also the source of some other bugs... I'm 
happy when I've fixed this, but it's not highest priority... (keyword: 
partial specialization)
> http://bugs.freepascal.org/view.php?id=24254 (CRITICAL! for 
> TArray.Sort<T>)
I don't consider this critical. It's a missing feature that needs to be 
implemented and will be implemented when time permits (though I'm 
looking forward to having this feature available :) )
> http://bugs.freepascal.org/view.php?id=24287 (Very Important!)
> http://bugs.freepascal.org/view.php?id=24072 (Very Important!)
Also part of "partial specialization"
> http://bugs.freepascal.org/view.php?id=24097 (Important!)
Forward declarations are encountered seldomly enough so that I don't 
consider this as important.
> http://bugs.freepascal.org/view.php?id=24064 (Important!)
Considering that your example does not compile in Delphi either and the 
way generics and units work I consider it as unlikely that I'll fix that.
> http://bugs.freepascal.org/view.php?id=24071 (Important!)
> http://bugs.freepascal.org/view.php?id=24285 (Important!)
> http://bugs.freepascal.org/view.php?id=24286 similar to 24285
> http://bugs.freepascal.org/view.php?id=24458
> http://bugs.freepascal.org/view.php?id=24098 (Frustrating)
That comes when Borland decides to use "<...>" for generic parameters... 
I could still kill them for that decision -.-
This won't be fixed for quite some time.
> http://bugs.freepascal.org/view.php?id=24073
> http://bugs.freepascal.org/view.php?id=24463

Regards,
Sven