Am 23.05.2013 12:22, schrieb Maciej Izak:



    Nice. Now I know where all those bug reports come from :P


 :D It's my pleasure. Aren't you happy?
Depends. On the one hand I'm happy that someone stresses the generics implementation to its limits (like JC Chu does as well), but on the other hand it means work in - in case of generics - a bunch of headaches... ;)

Are those available in Delphi as well? If not I see no use in them.
    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.


Yes, I know that. I need this only for shortterm. In that case for safety maybe we should remove System.Addr? ;) In Delphi they do that by special interfaces created for each type (lost of time and memory). First, I can't implement this by Delphi way because we have still a lot of generics bugs. Secondly, I think that we can do much more better implementation of Generics. This is not C#, in Pascal we have better access to pointers. Now I'm using (I hope temporarily):

=== code begin ===

  TValueAnsiStringHelper = record helper for AnsiString
    function GetValueSize: Integer; inline;
    function GetReferenceToValue: Pointer; inline;
  end;

function TValueAnsiStringHelper.GetValueSize: Integer;
begin
  Result := Length(Self) * SizeOf(AnsiChar);
end;

function TValueAnsiStringHelper.GetReferenceToValue: Pointer;
begin
  if Length(Self) <> 0 then
    Result := @Self[1]
  else
    Result := nil;
end;

 === code end ===
Etc. for other basic types.

I, really need this for custom comparers and equality comparers, for example:

=== code begin ===
while AComparer.Compare(AValues[I].GetReferenceToValue, P.GetReferenceToValue, AValues[I].GetValueSize, P.GetValueSize) < 0 do
// ...
if FEqualityComparer.Equals(AKey.GetReferenceToValue, LItem.Pair.Key.GetReferenceToValue, AKey.GetValueSize, LItem.Pair.Key.GetValueSize) then
 === code end ===

I still see no need for this. I would simply do

=== code begin ===

if FEqualityComparer.Equals(AKey, LItem.Pair.Key) then
  ...

=== code end ===

Why fall back to pointers for something like this if we can use static types?! And if that means that the comparer needs to be implemented for each type, then so be it (you could implement a default generic comparer, which uses the normal "=" operator, maybe some others for basic types like strings and a TObject.Equals based one and the other comparators should be supplied by the user). You can't do things as equality tests in a general way anyway (best example: case sensitive vs. case insensitive comparison of strings). If your concern is performance then you could declare the two parameters as "constref" so that they are passed by reference and not by value.


        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.


But with generics code for some types i don't have predefined operators (for example: records), and here is the problem with Generics Dictionary.
If your implementation of Generics.Dictionary needs certain operators than the type with which the dictionary is specialized needs to implement these operators. If the type does not: bad luck.
GetValueSize and GetReferenceToValue is in the same level as System.SizeOf and System.Addr.

I think it's a natural evolution System.SizeOf and System.Addr for Generics (to operate on values).
I see no need for a context sensitive SizeOf and your GetReferenceToValue is simply flawed, because you can't capture the correct location of a parameter passed by value as this is just a copy, no "@Self" will result in the correct value here. E.g.:

=== code begin ===

{$mode objfpc}

type
  TLongIntHelper = type helper for LongInt
    function GetSelfAddress: Pointer;
  end;

function TLongIntHelper.GetSelfAddress: Pointer;
begin
  Result := @Self;
end;

var
  l: LongInt;

procedure TestProc(aValue: LongInt);
begin
  Writeln(hexstr(aValue.GetSelfAddress));
  Writeln(hexstr(l.GetSelfAddress));
end;

begin
  l := 42;
  Writeln(hexstr(l.GetSelfAddress));
  TestProc(l);
end.

=== code end ===

=== output begin ===

0040B000
0140FE4C
0040B000

=== output end ===

There is no other language as FreePascal and it would be wrong to introduce something stupid to such an important system functions. If my thinking is wrong, please, any hint of an alternative. Without it, I'm completely stuck.

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

Reply via email to