Lars Fosdal

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.

Another challenge is knowing when NOT to refactor. "This code works, but it looks awful... should I refactor?"

Since threading is non-trivial, it is hard to make examples that are not either non-trivial or oversimplified. You may find yourself writing quite a bit of scaffolding code, which would have come for free with OTL.

What are your needs / goals?

Is the behavior erratic across multiple executions of the same application - or is it specific applications that do not let you capture?

True, but the point is a more natural limit of variable scope. var ref := Some.Array[Index1].Reference; var thing := Function(Index1).Thing; if ref.Value <> thing.Value then begin ... end; // ref and thing ARE present here I guess you could wrap it in another pair of begin/end - but that would look a bit strange, while the with signals clearly that these are local.