Zacherl

The var can actually make sense, if you think of the C++ move semantics. This way you could either implement a copy or a move assignment operator ... Would be nice if there was a way to implement both (same for constructors).

It's okay man. Can't help it, if you don't want to read the complete post (e.g. the text i quoted from the Intel SDM). I'm out.

Nothing more to say ...

You will need a lock prefix only, if you have concurrent threads reading, modifying (e.g. incrementing by one) and writing values. This is to make sure the value does not get changed by another thread in a way like this: T1: read 0 T2: read 0 T2: inc T2: write 1 T1: inc T1: write 1 By locking that operation, read + increment + write is always performed atomic: T1: read 0 T1: inc T1: write 1 T2: read 1 T2: inc T3: write 2 For forther explanation read this: If you only want to write values without reading and modifying of the previous value, no `LOCK` prefix is needed.

Well, okay seems like the Intel SDM needs to be updated. Did anybody test the same szenario with multi-threaded atomic write operations (`lock xchg`, `lock add`, and so on)? Could imagine different results in terms of performance here. Anyways .. I guess the original question is answered. To summarize this: 1 byte reads are always atomic 2/4/8 byte reads are atomic, if executed on a P6+ and fitting in a single cache line (any sane compiler should use correct alignments by itself) For multi threaded read-modify-write access, read this (TLDR: you will need to use `TInterlocked.XXX()`): https://stackoverflow.com/a/5421844/9241044

Sorry, but did you actually read my post? Thats exactly what I quoted from the latest Intel SDM: Can you please give me some references that proof your statement? Intel SDM says (you might be correct for normal data access, but using the `LOCK` prefix is something else):

Reading unaligned values from memory is slow but should still be atomic (on a Pentium6 and newer). This behavior is described in the Intel SDM: The above is only valid for single-core CPUs. For multi-core CPUs you will need to utilize the "bus control signals" (click here for explanation) : Delphi implements the System.SyncObjs.TInterlocked class which provides some functions to help with atomic access (e.g. `TInterlocked.Exchange()` for an atomic exchange operation). You should always use these functions to make sure your application does not run into race conditions on multi-core systems. BTW: I released an unit with a few atomic type wrappers some time ago (limited functionality compared to the `std::atomic<T>` C++ types as Delphi does not allow overloading of the assignment operator): https://github.com/flobernd/delphi-utils/blob/master/Utils.AtomicTypes.pas

That's exactly the problem and as well the reason for the warning. The OP does not actually override TObject.ToString but introduces a new method (because of the different signature). The override just does nothing.

You are correct ofc, but assertions are only used to detect programming errors (should be at least ^^) and allow for advanced tests like fuzzing, etc. They should in no case be used as a replacement for runtime exceptions. If a runtime exception occurs on a productive system, you need a real logging functionality included in your product to be able to reproduce the bug (independently of the assertions, which are always good to have 🙂 ). There is madExcept and stuff like that which will provide you callstacks in case of a runtime exception, but sometimes event that is not sufficient (e.g. in cases where code fails silently without exception and so on).

Should work 👍 Was just about to recommend adding an additional timeout to the code, but you already did with your error counter 🙂

I remember a that that discussed a similar topic .. it was something like "How to detect, if I can append data to a file". The solution was: Try it and catch errors. There are just too many variables that you would have to check (file exists, access privileges, exclusive access, ...). If you need cross-platform, I can just quote myself: There are other approaches, if cross-platform support is not needed, but none of them are easy (on Windows you could enumerate all open handles to the file e.g. or work with global `CloseHandle` hooks).

Isn't the optimizer smart enough to remove empty function calls? Well ... I know ... it's Delphi ... and Delphi is not really known for perfectly optimized code, but detecting empty functions is a really easy task. Using `IFDEF`s inside the logging function itself would be a better solution in this case. Edit; Well tested it, and ... ofc it does not eliminate calls to empty functions Generates a `CALL` that points to a single `RET` instruction instead. This should not happen in 2018.

Assert is fine, but sometimes you want to have logging code in your productive version. Asserting is not a good idea here as it will raise an exception. Besides that only one event can be logged at a time (as the application crashes after the first assertion / or executes the exception handler what will them prevent execution of successive assertions).

Just trying to open the file is already the correct solution IMHO. You should catch the exception and retry until it works.

This shitty code has been generated for ages now. Don't think they will ever fix this.