Leaderboard

People overuse generics and forget that the implementation often does not need generics at all: type TSupport = class helper for TObject private function __Supports(out ResObj: TObject; cls: TClass): Boolean; public function Supports<T: class>(out ResObj: T): Boolean; inline; end; function TSupport.__Supports(out ResObj: TObject; cls: TClass): Boolean; begin if Assigned(Self) and Self.InheritsFrom(cls) and not ((Self.InheritsFrom(TBoldObject)) and TBoldObject(Self).BoldObjectIsDeleted) then begin ResObj := Self; Exit(True); end; ResObj := nil; Result := False; end; function TSupport.Supports<T>(out ResObj: T): Boolean; begin Result := __Supports(TObject(ResObj), T); end; This code will not cause any bloat at all (in the final executable - see below for the situation during compilation though). What @ventiseis wrote is correct - the issues with long compile-time and possibly running ouf of memory (more so under the LLVM based compiler because they have a larger memory usage already) are real. They are caused by the compiler first compiling unit by unit and stuffing everything generic being used into each dcu just to (possibly) remove it again later during link time. Linker however will only remove exact identical duplicates such as if you have TList<TFoo> in multiple units executable will only contain it once, but it will also contain TList<TBar> and TList<TQux> even though they are also just lists for objects. Since XE7 most methods on TList<T> are marked as inline and unless you are using runtime packages they are not being called in your executable but the internal TListHelper ones but since all RTL classes have $RTTI turned on the binary will still contain all these methods. You only partially get rid of them by using {$WEAKLINKRTTI ON} which you need to put into each and every unit (years ago you could put that into the dpr and it affected all units but that was actually a compiler bug that made flags with scope local being global - but any unit that changed them then also changed them globally which caused quite some weird defects) That is why I did the huge refactoring in Spring4D regarding collections and the generic container registration API. If you use a list from spring with a thousand different classes the binary will only contain the code for the list once unlike with the RTL where you would have it a thousand times The issues are known and reported but obviously are not severe enough or too complex (especially the second one would require some architectural changes to how the compiler deals with generics): https://quality.embarcadero.com/browse/RSP-16520 https://quality.embarcadero.com/browse/RSP-18080

Hextor is a hexadecimal editor with a set of tools for binary data analysis and reverse engineering. Main features include structure analyzer, disassembler, regex-like search and many more. https://github.com/digitalw0lf/hextor I mostly write it as a tool for my main job tasks, but would be glad if it can be useful for community. Feedback and feature suggestions are welcome.

Not necessarily. In my Image32 graphics library, I'm using Delphi's JPEG unit without touching TBitmap. Edit: Sorry, the JPEG unit does use TBitmap.

That's what she said Sorry

It is not about small executables. It's about the delphi IDE which becomes which becomes unresponsive and suffers from long compile and link times (including cases of EOutOfMemory). For example, we have an internal library using derived generic TList class. And we have a lot of business model objects stored in this list class. For each and every generic list object type, all methods of TList are compiled again into the executable, even if they're doing the same thing. Perhaps with some trickery one would be able to replace this list class with a non-generic version. I only wanted to add the comment that it is nice to have clean and working generic code but that it has a downside, too.

check your Delphi shortcuts for an assigned key-combo, it makes no sense what you are telling us