[fpc-devel] Generics.Collections as package for Lazarus or package for FPC RTL

Maciej Izak hnb.code at gmail.com
Wed Jan 27 23:41:07 CET 2016


2016-01-27 17:24 GMT+01:00 Sven Barth <pascaldragon at googlemail.com>:

> I'll need to look at your code again, but even for class functions the
> same rules (and worries) as for normal methods apply.
>
I hope that your research in Generics.Defaults will be successful for
manual interfaces :P

Most important about manual interfaces, and why can't be used any other
solution without painful consequences:

1. we don't want to use ARC interfaces (for singletons created at startup
in Generics.Defaults)
side note: in Generics.Defaults is introduced TSingletonImplementation for
non ARC COM interfaces

2. even if point 1. is simple to achieve, it brings a lot of problems
because we need to keep somewhere our singletons and that means:

SIGSEGV exception is guaranteed, during closing application in many
scenarios

program X;
uses
  A, B;
begin end.

A source code:

unit A; interface uses Contnrs;
  var GarbageCollector: Contnrs.TObjectList;
implementation initialization
  GarbageCollector := Contnrs.TObjectList.Create(true);
finalization
  GarbageCollector.Free;
end.

in B is used A and Generics.Collections.

unit B; interface uses A, Generics.Collections; implementation
begin
  GarbageCollector.Add(TDictionary.Create);
end.

Generics.Collections (which is using Generics.Defaults) and our
Generics.Defaults is released before A. It will cause a memory violation in
Generics.Defaults for our singleton O__o.

To avoid this memory violation is necessary to omit point 1.

3. To avoid memory violation, any instance of collection should be owner of
instance of IComparer / IEqualityComparer and that is performance and
memory killer in comparison to manual interfaces.
-- 
Best regards,
Maciej Izak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20160127/18dd67c2/attachment.html>


More information about the fpc-devel mailing list