Lars Fosdal

Which is why I started with

By keeping current, you will deal with changes, one version at a time. After the D5->XE2 experience, I very much prefer that option. @Fr0sT.Brutal mentioned 64-bit. We didn't even go there yet, as the 64-bit debugger is utter and completely crap.

The worst breaking changes were Ansi -> Unicode. Migrating a million line D5 project to XE2 was something that I would prefer not to attempt again. Since then, there are been mostly type or constant renames, which are trivial in comparison. Other challenges have been the deprecation of BDE and dbExpress. Fortunately, FireDAC turned out quite well. I agree that the transition between the "named" version has been pretty much trivial, but then again - we usually don't migrate until the first Update pack shows up Last night, four of our SQL Servers that still linger on 2008R2 refused to accept schema updates for two specific stored procedures that were using functions only found in 2012 and upwards. The rest of our servers are 2012 and 2016/17. That is a similar risk to your components no longer getting updates for your Delphi version since the component author drew a line in the sand and started using language features or classes that only exist in the newer Delphi versions.

From my experience, the complexity of dealing with multiple generations of breaking changes has been far more expensive in man-hours than the cost of keeping current. Of course, that does not necessarily apply for everyone, and I can understand the cost perspective for a one-man shop - but for a corporate developer that is continuously developing internal systems, it is a no-brainer to stay current. You get the fixes, you get the support, and since we do relatively frequent releases, we do the testing anyway. Rio -> 10.4 will mean a lot of work on the FMX side - but on the bright side - you can finally stop having to think about two memory models when you write code for cross-platform. That dual model has actually been a roadblock for cross-platform for us. We did not want to spend time on that duality.

I've never set these up, but isn't that something you would configure on ISS itself, and then refer to from Delphi? Lots of security angles to consider

Here is a variation I use - I like type safety. type Setting = record i: integer; s: string; d: double; constructor Create(const _i: integer; _s: string; _d:double); end; Option = record const One: Setting = (i:1; s:'First'; d:0.01); Two: Setting = (i:2; s:'Second'; d:0.02); Three: Setting = (i:3; s:'Third'; d:0.03); class function Add(const _i: integer; _s: string; _d:double): Setting; static; // Sugar end; constructor Setting.Create(const _i: integer; _s: string; _d: double); begin i := _i; s := _s; d := _d; end; class function Option.Add(const _i: integer; _s: string; _d: double): Setting; begin Result := Setting.Create(_i, _s, _d); end; procedure Foo(const Options: TArray<Setting>); begin for var Option: Setting in Options do if Option.i in [2, 4] then Writeln(Format('i:%d s:%s d:%f', [Option.i, Option.s, Option.d])); end; procedure TestFoo; begin Foo([Option.One, Option.Two, Option.Three, Option.Add(4,'Fourth',0.04)]); end;

Not having basic DB and Linux support in the Pro SKU is lunacy.

Not sure that I understand the full context, but assuming you have an instance of TB in TA, overriding TA.AfterConstruction would allow you to assign self to that instance of TB?

I have to admit that there are parts of our Delphi code that I want to move to .NET Core and C# - mostly because that makes it far easier to integrate it with other solutions we have on the MS platforms. That said - doing end-user applications for Windows in C# is nearly unthinkable.

/blush

I would expect the hash generator you apply to your key would be pretty significant. My hashing needs are typically focused on strings shorter than 100-something chars, Int32 references, or Int64 references, typically varying from a few hundred to less than twenty thousand elements.

Food for @Daniel

Which applies to the TDictionary hashing, I see. Thank you, @Kas Ob. It is entirely possible that my prime size cargo cult stems from this article https://web.archive.org/web/20080515141600/http://www.concentric.net/~Ttwang/tech/primehash.htm which is a different algorithm than the Delphi one.

I opened the file as a binary file in a hex viewer and there were no FF or FE bytes.

I didn't make a claim. I asked a question. You answered. I asked if there was a mathematical proof that supported your answer. The other thread I mentioned seems to indicate that prime sizes have a purpose, so I'd like to understand. This is off topic for this thread, so please respond in the other thread or in DM.

@Kas Ob. It was a direct cut/paste from BDS to the forum editor in Chrome - so hard to say where the $FEFF was introduced. I can't replicate that error using BDS or VSCode. A proper realtime OS with a functional nanosleep is a better choice than windows for high resolution timing, I suppose.

Is there mathematical proof for that?

Anyways - under Windows, we have the so-called multimedia timer, https://docs.microsoft.com/en-us/windows/win32/multimedia/about-multimedia-timers but a caveat is that actual minimum resolution varies with platform and device https://docs.microsoft.com/en-us/windows/win32/multimedia/timer-resolution var TCaps: TTimeCaps; // WinAPI.MMSystem; rc: MMResult; begin rc := timeGetDevCaps(@TCaps, SizeOf(TCaps)); // WinAPI.MMSystem; if rc = 0 then Writeln(Format('Min %d / Max %d', [TCaps.wPeriodMin, TCaps.wPeriodMax])) else Writeln(Format('timeGetDevCaps returned %d', [rc])); end; outputs Min 1 / Max 1000000 on my computer. Oddly enough, the resolution is 1ms - so, in theory it is impossible to use a timer to get a better resolution than 1 ms. Still - the WaitableTimer has 100ns resolution, so that should work, right? https://docs.microsoft.com/en-gb/windows/win32/api/synchapi/nf-synchapi-setwaitabletimer function NanoSleep(const NanoSec: Int64):Boolean; var Timer: THandle; Constraint: _Large_Integer; begin Result := False; Timer := CreateWaitableTimer(nil, True, nil); if timer <> 0 then try Constraint.QuadPart := -NanoSec; if SetWaitableTimer(Timer, Constraint.QuadPart, 0, nil, nil, False) then begin WaitForSingleObject(Timer, INFINITE); Result := True; end; finally CloseHandle(Timer); end; end; but even that is incredibly erratic. const ns: Int64 = 10000; var st: TStopWatch; ix: Integer; begin st := TStopWatch.StartNew; for ix := 1 to 10 do NanoSleep(ns); st.Stop; Writeln(st.ElapsedMilliseconds); end; and does not seem to work at low intervals - unless I screwed something up? Windows is not a real time OS - so it seems milliscond timing will be iffy - unless you use a power consuming loop of instructions - and that is not desirable.

I am curious - when would you need such minuscule intervals?

TRttiType.GetProperties.GetAttributes vs TRttiType.GetFields.GetAttributes Personally, I've avoided setting props on fields and only set them on properties. There are parts of the RTL where the opposite applies - f.x. for REST.JsonReflect, which checks the fields and not the properties.

Guilty. Like OOP, Generics are sooo addictive!

My first thought was - why not use a thread with sleep if you need that fast a timer - but - again, multithreading raises its own issues.

What about the theory that dictionaries have fewer collisions if you set the capacity to be a prime number ? Fact or fiction? Personally, I do actually set the capacity to a prime, but I am not quite sure if it because it is sound advice or if it is a cargo cult thing. Edit: Funny enough, @Tommi Prami posted an alternative approach.

Less readable code can be greatly alleviated with decent commentary. Document general intent and method rather than say what each line does.

Empirically proven to work. "Awful" can be - slow code, albeit in a context where performance is not required - cryptic code - code that could be simplified with modern RTL code Anyways - Refactor when you need to, and not just because you'd like to - unless unlike most devs, you have time to spare. Oh - as @Stefan Glienkesuggests: Make sure you have the tests to validate your refactoring.