Does anyone see a reason why the internal array in TList in System.Generics.Collections is not of TArray but array of T (redeclared so it can be returned by the List property in newer XE* versions)?

-
Does anyone see a reason why the internal array in TList in System.Generics.Collections is not of TArray but array of T (redeclared so it can be returned by the List property in newer XE* versions)?

I was wondering because I was going to change that in Spring4D (also array of T until now but it will be easier with TArray because of type compatibility in some cases)

Comments

  1. Uwe RaabeApril 25, 2014 at 8:56 AM

    Perhaps because DataSnap is able to marshal a field of type but not one of TArray?

    ReplyDelete
  2. Stefan GlienkeApril 25, 2014 at 9:19 AM

    IOW perhaps a workaround for a RTTI bug (that hopefully is fixed by now)?
    I know the RTTI had some issues with TArray. But by the time the Items property (which is bad design imo - see http://stackoverflow.com/questions/22713780/why-is-generics-collections-tobjectlist-list-unsafe) was introduced because using the generic lists in the RTL required direct array access that error should have been fixed.

    ReplyDelete
  3. Kenneth CochranApril 25, 2014 at 9:51 AM

    More likely TArray didn't exist when TList was developed and there wasn't a compelling reason to change it. IIRC TArray was added in 2010.

    ReplyDelete
  4. Stefan GlienkeApril 25, 2014 at 10:22 AM

    Kenneth Cochran At least when they needed to declare that arrayoft type that is needed for the Items property someone might have used his brain and thought about changing it to TArray.

    Uwe Raabe Not familar with DataSnap but why would it need to marshal that field? And if it would that would be some leaky abstraction.

    ReplyDelete
  5. Kenneth CochranApril 25, 2014 at 11:44 AM

    Just looked in Delphi 2010's Generics.Collections. There is a commented out function in TList.

        // function ToArray: TArray; // pending compiler support

    This partially explains the implementation although I agree. This could have been fixed in XE when they added the compiler support.

    In XE ToArray is implemented although it uses a for loop to copy the elements using the Items property rather than using System.Copy or System.Move, which one would think would be more efficient. I could be overlooking something though.

    ReplyDelete
  6. Stefan GlienkeApril 25, 2014 at 12:03 PM

    Kenneth Cochran Don't know about the effiency but if FItems were TArray the ToArray method could look as simple as this (it does in Spring4D):

    Result := FItems;
    SetLength(Result, FCount); // this causes cow

    Also I think ToArray already worked in 2010 since Spring4D has it and it works.

    ReplyDelete
  7. Arioch TheApril 26, 2014 at 8:11 PM

    Kenneth Cochran you cannot bit-blit a complex ref-counted types like strings, dyn-arrays, interfaces. Tricks like that made generics in 2009 totally unusable

    ReplyDelete

Post a Comment