Leaderboard

Original post: https://www.thedelphigeek.com/2019/02/design-patterns-with-delphi-book.html Hurrah, hurray, my third book is here! It’s called Hands-On Design Patterns with Delphi and (just like my first book) I wrote it for Packt Publishing. (The second book was self-published and I expect the fourth one to be, too.) As the name says, “Design Patterns with Delphi” deals with design patterns. It is a bit different from most of design pattern books and websites you will find on the Internet. Case in point A: There are no UML diagrams. I don‘t speak UML. Tried to learn it few times but for some reason the whole concept doesn‘t agree with me. If you like diagrams, don’t fear though. Any book on design patterns - and most websites covering that topic - will gladly show how any design pattern can be diagrammed. That, however, is not important and should not govern your decision to buy the book. More important is case in point B: This book speaks Delphi. All the examples are written in Delphi and language features are used to the full. I also covered few less known Delphi idioms in separate sections. You’ll still be able to follow the discussion even though you may program in a different Pascal dialect. There’s also case in point 😄 Examples make sense. I deeply dislike classical design pattern examples of the “And then we want to write this program for different toolkits and it should also be able to draw circles, not only squares” kind. Euch! I tried to find a good example for each design pattern. Admittedly, I ended with few examples that draw triangles and squares on screen (mostly because some patterns were designed specifically for solving such problems), but most of them are of a more practical nature. This book covers all three classical design pattern categories - Creational patterns, Structural patterns, and Behavioral patterns. It also discusses patterns from the newer Concurrency patterns category. At the end I threw in some borderline-pattern(ish) topics and ended with a discussion of few patterns that cannot be strictly classified as “design” patterns. In this book you’ll find: Chapter 1 An introduction to patterns. Exploration of design principles, design patterns, and idioms. A mention of anti-patterns. A short description of most important design principles. Delphi idioms: creating and destroying objects. Chapter 2 Creation patterns part 1. Singleton. Dependency injection. Lazy initialization. Object pool. Chapter 3 Creation patterns part 2. Factory method, Abstract factory, Prototype, Builder. Delphi idioms: Assign and AssignTo. Chapter 4 Structural patterns part 1. Composite. Flyweight. Marker interface. Bridge. Delphi idioms: comparers and hashers. Chapter 5 Structure patterns part 2. Adapter. Proxy. Decorator. Facade. Delphi idioms: replacing components in runtime. Also: helpers. Chapter 6 Behavioral patterns part 1. Null object. Template method. Command. State. Chapter 7 Behavioral patterns part 2. Iterator. Visitor. Observer. Memento. Delphi idioms: for .. in. Chapter 8 Concurrency patterns part 1. Locking. Lock striping. Double-checked locking. Optimistic locking. Readers-writers lock. Delphi idioms: tasks and threads. Also: bitwise operators. Chapter 9 Concurrency patterns part 2. Thread pool. Messaging. Future. Pipeline. Chapter 10 Writing Delphi programs. Event-driven programming. Actions. LiveBindings. Form inheritance. Frames. Data modules. Chapter 11 Wrapping it up. Exceptions. Debugging. Functional programming. I hope you will like this book and learn a lot from it. I know I did during the nine months I spent writing it. And if you find any bug in the code, let me know so I can correct it in the second release!

Storing records in collections is a delicate topic as usually the code is a bit more complex than just storing integers or pointers. Even more so if the record has managed types like string. In this case the simple fact of having a local variable of T inside your generic code and doing one assignment more than necessary (because for example passing some olditem to a notification) might cause a severe slow-down. If you put such code into a single method it does the stack cleanup and finalization for that variable in all cases even if there is no notification to be called. The code in Rapid.Generics is using some shortcuts and produces even more convoluted code than System.Generics.Collections has since its refactoring in XE7. It does for example not use TArray<T> as backing storage for its list but pure pointer math. It also does not zero memory for this array which buys some speed by not doing the round trip to those all the code happening in System.DynArraySetLength - especially for managed types. That buys a bit of performance when adding items - especially if you don't set the capacity before. I know that the RTL collections had a ton of bugs caused by that refactoring as certain typekinds suddenly were not handled properly - I don't see any unit tests for Rapid.Generics though so I would not say that they are working for all kinds of types that you might store in those lists. As for the specific case of Clear taking longer in the RTL collections that is another optimization being done in Rapid.Generics where it simply cleans up the memory and is done whereas the RTL runs through some extra code which is not necessary if there is no OnChange attached to the list. Edit: I looked into the Rapid.Generics code for records and it maintains its own mechanism to cleanup any managed fields with a small performance improvement if the field is actually empty. This causes a major speedup if you are doing some benchmarks with empty records but I guess with real data this won't give much. I tested with a small record with 2 string fields and an integer and when they were empty the Clear call was very fast compared to the RTL list but not so much anymore when the fields contaied some strings that it had to cleanup.

Hi Developers, Deleaker was created in 2006, and is been support Visual Studio from the very first release. Now it's time to find leaks in Delphi and C++ Builder! Deleaker finds memory leaks, leaks of GDI and USER32 resources, handles and many others. Deleaker fully integrates with RAD Studio. Here the official announcement: https://www.deleaker.com/blog/2019/03/11/integration-with-rad-studio/ Let's look how it works! Download Deleaker and launch it. Now you can select versions of RAD Studio you want Deleaker to integrate with. Of course, RAD Studio Rio 10.3 is supported: Deleaker is installed, let's launch Delphi: Great, Deleaker is here: Let's add some leaks: Start debugging, click the button, exit. Deleaker is taking a snapshot: Two leaks are shown as expected. It's easy to navigate to source of a leak: Happy coding!

I'm using System.Generics.Collections so far and was only interested in comparing my component with rapid.generics. My "small" benchmark does not say anything in detail but it shows, that the Rapid is doing create and free faster. Before this can be used the source should be checked for threadsafe etc ... Our component stores a lot of information in a "tDictionary<string, __Record>;" where the __Record is defined as __Record = record public isObject, doFreeObject:boolean; vname:string; vname_original:string; vname_2, vname_3, vname_4:string; vwert:variant; vdescription:string; vcomponent:tobject; vdtstamp:tdatetime; end; Important to see was only the speed-difference on my machine, and it is a noticeable difference with Rapid.Generics so the programmer is doing something right in my opinion.

I have tested my component for Generics-Collection with Tokyo 10.2.3 and Rio 10.3.1 with same results: Adding 100.000 data / read in order 0 to 100.000 / read 100.000 times random / free Tokyo: 1417ms / 59ms / 67ms / 234ms Tokyo with Rapid-Generics: 705ms / 49ms / 69ms / 26ms Rio: 1415ms / 59ms / 65ms / 230ms Rio with Rapid-Generics: 671ms / 51ms / 69ms / 26ms So the results between Tokyo and Rio are the same! But Rapid Generics is faster with adding (increment) and freeing (.clear)

Yes, mine arrived yesterday.

The code needs max log(maxint) steps for the first and the second loop, max 9 steps for the third loop. As the integer size is constant for a given platform, this is just O(1).

No, in your example both loops will be O(INFINITE). Well, not quite. It would be O(MaxDouble / x) to be precise.

First 2 loops are O(log n) and O(log m). The last loop is clearly O(9) due to the bound but the O(9) is "asymptotically equal" to O(1). Overall you have O(log n + log m + 1) where 1 is constant so only n and m are involved. That complexity is O(log n + log m) but to be correct it would be O(log max{m, n}) where max gives you the biggest value between m or n. Do not say that for loops are O(n) by default, that would be a wrong assumption! Example here: https://stackoverflow.com/questions/10039098/why-is-this-function-loop-olog-n-and-not-on Look this example: var x: double; //x = 1000 maybe while (x > 1) do x := x * 0.3; You are executing this loop many times, let's say n, and so you are taking x * (0.3^n) and you want it to be bigger than something, in this case 1. Now you need to get n from that equation but n is an exponent so you can use logarithms to take the n down like: x * (0.3^n) = 1 -> log(0.3^n) = log(1/x) -> nlog(0.3) = log(1/x) and so on, at the end you'll get an asymptotic O(log n). This is probably not the place to demonstrate what I am saying but if you understand math topics like "limits" and "asymptotes" you can google for this and see that there are methods like substitution, master theorem or trees to get the O(something) notation

To some extent theming has a purpose because without it you could not have dark theme. Problem here is that Delphi (VCL Styles) based theming is just horrible since day one (even before it was introduced in IDE). Instead of VCL Styles being fixed and then used at large, EMBT choose to use VCL Styles without fixing issues. Another problem is not that just in theming itself, but revamping Options dialog layouts without making proper alignment/size adjustments - so everything visually just falls apart.

I really don't get the whole theming bull anyway. I set my windows to look exactly the way I want it, and along comes some wannabe designer and imposes his take on what a GUI should look like. Most of the time it's just hilarious, but when I have to work with a tool (yes a tool) I want it to be as unobtrusive as possible and just do it's thing. If i want glitter on a hammer I will buy glitter and stick it on there myself. Don't expect everyone to like glitter an a hammer. Jeeeez! </Rant>

For those who write their own generics, you have two ways to do this: the naive but generic way, which can still result in code bloat, and the System.Generics.Collections way, which goes against almost every prinicple of generics, i.e. that you don't have to repeat yourself ad infinitum. I wrote about that already: The current state of generics What they did with the new intrinsics solves part of the problem for their own classes, but it certainly doesn't solve the problem for us who would like to write generics without having to worry about code bloat and without having to do a lot of "copy-and-paste generics". If they can make the compiler select different pieces of code depending on these new intrinsics, they can just as well make the compiler generate such code without us having to worry about it. That is more work, but that is how it should be. In the meantime, they should also finally fix Error Insight (not only for the new inlined vars) and make the new themed IDE a lot more responsive.

You have a problem so you decide to use threads. you problems.2 have Now

https://github.com/ahausladen/JsonDataObjects by Andreas Hausladen

@David Millington Can you - or Embarcadero - please publish Bookmarks and Navigator 1.6 for older platforms? Or create a version that does not depend on share "Core" DLL? I think the community would very much appreciate it. I know I would.

Is there a FixPack for 10.3.1 ?