More generic examples from my answer to the above question:
In XSD you can derive from an existing type in two ways: extending it and limiting it. Object Oriented languages only allow you extend when deriving.
Delphi is not alone in these kinds of limitations. Generating wrappers from XSD schema’s is the field of specialized tools, even in the Java or .NET world.
I’ve seen horrible things with wildcards that are sort of mappable to Java, but not to C#. This could likely go on for much longer…
Design Patterns and Refactoring articles and guides. Design Patterns video tutorials for newbies. Simple descriptions and full source code examples in Java, C++, C#, PHP and Delphi.
They basically allow you to use attributes on interfaces to define a type-safe wrapper around any REST interface, then instantiate a connection to it for making calls.
No more manual HttpClient fiddling!
Since it requires only .NET 1.4, you can basically run it on any platform as it’s supported covered by the implementations .NET Core, Mono and the full .NET Framework.
Quite a lot of projects already use it; I got there via the first link:
Ah, C. The best lingua franca we have… because we have no other lingua francas. Linguae franca. Surgeons general? C is fairly old — 44 years, now! — and comes from a time when there were possibly more architectures than programming languages. It works well for what it is, and what it is is a relatively simple layer of indirection atop assembly. Alas, the popularity of C has led to a number of programming languages’ taking significant cues from its design, and parts of its design are… slightly questionable. I’ve gone through some common features that probably should’ve stayed in C and my justification for saying so. The features are listed in rough order from (I hope) least to most controversial. The idea is that C fans will give up when I call it “weakly typed” and not even get to the part where I rag on braces. Wait, crap, I gave it away.
A network graph with more than a thousand programming languages connected by influence relations. Highly influential languages like Lisp, Smalltalk, C, Java, Pascal, C++, Haskel or Python are shown as larger circles as compared to languages with little influence on others like PHP or Argh!. / The influence relation data was retrieved from Freebase in 2013. This design available on posters and other products. An awesome gift for programmers who are into digital art. • Also buy this artwork on wall prints, apparel, kids clothes, and more.
[WayBack] Eric Grange (of [WayBack] DWS and [WayBack] beginend.net fame) mentions he tends to use 1.5, it is about as good as 2 for small lists, but reduces waste for large ones. He also uses a constant delta to accelerate growth early on, so something like:
FastMM small block allocator sizes (size includes the leading header) are: 8, 16, 24, 32, … 160 (in +8 steps), 176, 192, … 320 (+16), 352, 384 … 480 (+32), 528, 576, … 672 (+48), 736, 800, 880, 960, 1056, 1152, 1264, 1376, 1504, 1648, 1808 , 1984, 2176, 2384. [FastMM4.pas, SmallBlockTypes global var]
While the size of reallocated region fits inside a small block (with a different size than a previous block), the data is moved around (new block is allocated from a new suballocator). If it is too big (>2384 bytes), it gets allocated from the medium block allocator (which handles all block sizes up to 264752 bytes; larger blocks come directly from VirtualAlloc).
When small blocks are reallocated (to a larger size), allocator always allocates at least 100% + 32 bytes larger block, even if less is requested by the RTL (example: 8 bytes will grow to 2*8 + 32 = 48 bytes). When medium blocks are reallocated, allocator always allocates at least 125% of the old size. This boosts the performance when blocks are enlarged by small values as they can be enlarged “in place” (no data moved around, just the header is adjusted).
Stefan Glienke and Primož Gabrijelčič then concluded that:
Resizing an array from say 4 elements (pointer size) to 1000 (in multiple steps) will for sure move several times when jumping from one region into the next larger one.
Changing to a growth factor of 1.5 vs 2 won’t change anything in terms of memory fragmentation in FastMM4.
I recently experimented with different grow factors and while the memory fragmentation can only mitigated for medium and large blocks (where it actually matters imo) it might be beneficial to only grow by 1.5 at that point. But that has yet to be tested.
What I liked so far is the grow strategy that Go uses (2x until 1024, 1.25x after that) – see https://golang.org/src/runtime/slice.go#L115
Since you usually set the size upfront if you add many elements at once (well, if you know how many beforehand) the grow strategy only matters in the long run. You want to balance speed (too many realloc might slow things down unnecessarily), memory overhead (if you are overallocating much you risk wasting too much memory) and memory fragmentation (which might happen with a grow factor bigger than the golden ratio)
The trick comes down to enabling the PreferExternalManifest registry setting and then create a manual manifest for the application that forces the application to use “bitmap scaling” by basically telling it does not support “XP style DPI scaling”.
You name manifest file named after the exe and stored it in the same directory as the exe.
After that, you also have to rename the exe to a temporary name and then back in order to refresh the cache.
A quote from the trick:
In Windows Vista, you had two possible ways of scaling applications: with the first one (the default) applications were instructed to scale their objects using the scaling factor imposed by the operating system. The results, depending on the quality of the application and the Windows version, could vary a lot. Some scaled correctly, some other look very similar to what we are seeing in SSMS, with some weird-looking GUIs. In Vista, this option was called “XP style DPI scaling”.
The second option, which you could activate by unchecking the “XP style” checkbox, involved drawing the graphical components of the GUI to an off-screen buffer and then drawing them back to the display, scaling the whole thing up to the screen resolution. This option is called “bitmap scaling” and the result is a perfectly laid out GUI.
In order to enable this option in Windows 10, you need to merge this key to your registry:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide]
"PreferExternalManifest"=dword:00000001
Then, the application has to be decorated with a manifest file that instructs Windows to disable DPI scaling and enable bitmap scaling, by declaring the application as DPI unaware. The manifest file has to be saved in the same folder as the executable (ssms.exe) and its name must be ssms.exe.manifest. In this case, for SSMS 2014, the file path is “C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\ManagementStudio\Ssms.exe.manifest”.
Paste this text inside the manifest file and save it in UTF8 encoding:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
This “Vista style” bitmap scaling is very similar to what Apple is doing on his Retina displays, except that Apple uses a different font rendering algorithm that looks better when scaled up. If you use this technique in Windows, ClearType rendering is performed on the off-screen buffer before upscaling, so the final result might look a bit blurry.The amount of blurriness you will see depends on the scale factor you set in the control panel or in the settings app in Windows 10. Needless to say that exact pixel scaling looks better, so prefer 200% over 225% or 250% scale factors, because there is no such thing as “half pixel”.
The Wiert Corner - irregular stream of stuff 