David Heffernan

In C++ you can prevent it from happening.

This is still an enormous weakness in the language.

It's fairly clear that the Delphi language we are referring to was designed to make such types assignment compatible. That is made clear by the documentation for the Delphi language. There are other languages that have taken different approaches, but we aren't discussing those languages here. We are discussing Delphi. Whilst you might wish that a different decision had been taken, it wasn't. It's really not likely to change.

But the language was designed differently. Use records. What's so difficult about that?

Since the language regards these two types as assignment compatible, it's pretty hard to imagine adding warnings or hints when you write such assignments. Wrap the value in distinct record types.

Fair enough.

You'll need to declare two record types for this. The language isn't going to change now.

@Stefan Glienke And the existence of two byte data that cross cache lines shows that unaligned access is not atomic. When arguing about non deterministic properties like atomic access or thread safety the language used is a little different. When we say code is. It threadsafe we don't mean that it will always fail. We mean that we can't guarantee that it will always succeed. When we say memory reads are not atomic we don't mean that they won't always be read with multiple bus reads. We mean that we can't guarantee that they will always be read with a single bus read.

You agree then that unaligned access of data greater than a single byte is not atomic?

That's what you said.

Yes, I read what you wrote. What you wrote was wrong. You said nothing about cache lines.

There's nothing to switch off. You choose to switch it on on a type by type basis.

Single bytes are aligned, because they can't straddle cache lines. Reads are therefore atomic, because they are aligned. Two byte reads can straddle cache lines and unaligned reads are not atomic.

Actually both of these statements are wrong. Reading unaligned memory is not atomic for reads that straddle cache lines. And unaligned memory access is not slow on modern processors.

The IDE's tools aren't well designed in my view. Don't set the version information that way, instead make it part of your automated build process.

It's not that the override does nothing. There is no override. It makes no sense to me to reintroduce a method of that name.

Why don't you override the method from TObject?