Is there a reason why the RTL supports so few interfaces?
Is there a reason why the RTL supports so few interfaces?
E.g. TStrings does not support IStreamPersist, even though it does have the compatible methods.
On the other hand TGraphic does support that interface. I fail to see the difference between TGraphic and TStrings in this regard.
E.g. TStrings does not support IStreamPersist, even though it does have the compatible methods.
On the other hand TGraphic does support that interface. I fail to see the difference between TGraphic and TStrings in this regard.
About using generics on internal data structures, the most new components are using it, ie app tethering. FMX uses them
ReplyDeleteThe reason should be what David Millington said, not wanting to maintain legacy code
Agustin Ortu
ReplyDeleteThe codebloat due to generics is really quite bad, and there is no benefit to the user. The FMX code is all post generics so it makes sense there. In the VCL however I'd stick to the default lists.
Every interface, and every class in the inheritance hierarchy that exposes a new interface adds some bloat, both statically and at runtime.
ReplyDeleteDelphi being statically compiled, interfaces have a "cost", that is much more pronounced than in JIT'ed & GC'ed languages. In a JIT'ed language it is possible to optimize interfaces in many ways.
In Delphi, every method that is related, directly or indirectly to an interface cannot be smart-linked, thus further adding to the bloat. They cannot be inlined. They involve non-negligible implicit exception frames.
Also interfaced objects have non-trivial initialization overhead, and introduce a risk of memory leak in Delphi (circular references).
FMX is making heavy uses of interfaces and generics... but it is also not anywhere near the performance level or compacity usually expected from static/native code...