Posts

Are generics slow?

Image
In the TCoffeeAndCode session about "Code Profiling, Optimization, Performance, and Memory Leaks", it has been mentioned that generics are slow. However, no specific details were given, and this topic deserves to be explained in more detail before people start indiscriminately removing generics from their codebases, hoping to gain some speed. You can watch the session replay at: https://www.youtube.com/watch?v=hCFZv0I9TUk (minute 56) How generics work In order to understand how generics can impact speed, we need to know how generics work under the hood and why they are useful. The simplest way to explain generics is to imagine you have some particular code you need to run on different types. And to achieve that, you copy-paste the code and replace one type with another and nothing else. This is how generics work in C++, where they are not called generics, but templates. Instead of you having to copy-paste code and replace types, the compiler does that for you. Generic c

Virtual methods in Delphi

Image
Virtual methods enable subtype polymorphism - in other words, they allow implementing different behavior in descendant classes. That means if you have a base TShape class with a virtual Paint method, and several descendant classes like TRectangle , TCircle and TTriangle , then each of those subclasses can implement a different Paint method to appropriately paint itself. You can call the Paint method on any shape instance without needing to know which kind it is, and it will be correctly painted. Static vs dynamic dispatch Virtual methods can achieve polymorphism via a mechanism called dynamic dispatching at runtime, while non-virtual methods will be statically dispatched (bound) during compilation. Polymorphism cannot be achieved by statically bound methods—in other words, when you call a statically bound method, you will call the same implementation for all descendant classes. Static dispatching means that the compiler will resolve the method address at compile time, and will

Building better serialization

Image
The "When in Rome, do as the Romans do" blog post series used serialization as an example of what happens when applying inappropriate coding patterns for some language. It demonstrated how field-based serialization does not fit well in Delphi, and how published-property-based serialization is more appropriate. But it also briefly covered some poor serialization practices, that are not language-specific. For instance, attribute-based configuration is widely used across various languages and serialization frameworks, and for the same reasons such a configuration style is a poor practice in Delphi, it is a poor practice in any other language. Knowing what constitutes a good serialization framework is important regardless of whether you are assessing an existing framework or building your own. While this article approaches serialization from a Delphi point of view, the listed principles are valid in—and can be applied to—any language. Configuration and attribute based seriali

When in Rome, do as the Romans do - Part III

Image
In Delphi, properties can be backed by simple fields, but they can also have getter and setter functions that can be vital to the proper functioning of a class. They can contain additional initialization code, protect the consistency of the object's data, prevent invalid input... Photo: Gary Todd from Xinzheng, China, PDM-owner, via Wikimedia Commons, https://commons.wikimedia.org/wiki/File:Colosseum_(48412957912).jpg As you might guess, field-based serialization does not call the appropriate getters and setters, and can cause runtime malfunctions. On the other hand, property-based serialization calls getters and setters if any exist. This is another thing to consider when using REST.Json , which uses field serialization instead of property serialization. REST.JSON ignores property setters https://quality.embarcadero.com/browse/RSP-26262

TCoffeeAndCode: Threading and Concurrency Replay

Image
Did you miss the TCoffeeAndCode session on "All about threading and concurrency"?  The webinar replay is now available!  Hosted by Jim McKeeth and his guests: Frank Lauter, Primož Gabrijelčič, Olaf Monien, Kelver Merlotti and Dalija Prasnikar.   https://www.youtube.com/watch?v=KosLWa08X4Q

Mastering Delphi Memory Management Webinar Replay

Image
In case you missed the live session, webinar replay Mastering Delphi Memory Management where I am answering your questions about memory management is available on YouTube.  Book intro by Neven Prasnikar Jr. followed by a recording of live Q&A chat hosted by Jim McKeeth. Webinar replay: https://www.youtube.com/watch?v=_0_cUcygmLU Book info: https://dalija.prasnikar.info/delphimm Thank you all for joining live session and watching!

When in Rome, do as the Romans do - Part II

Image
In the previous article, we learned that native Delphi serialization is based around published properties, and that other kinds of serialization, like field-based serialization, don't fit well with the Delphi model. Photo: Gary Todd from Xinzheng, China, PDM-owner, via Wikimedia Commons, https://commons.wikimedia.org/wiki/File:Colosseum_(48412957912).jpg We have also learned that property-based serialization has some limitations and that it does not have out-of-the-box support for the serialization of records, arrays, or indexed properties, and you can only serialize collections defined as TCollection , whose items are descendants of TCollectionItem . While serialization as a concept is widely used to convert any kind of objects into various storage formats, the main purpose of the Delphi serialization model being built on top of published properties and descendants of TComponent was to serialize the user interface and data modules. This is where the original type limitati