David Heffernan

The fact that you regard this topic as important. That you feel it's important to count errors beyond one. The fact that sometimes delphi emits two warnings for the same issue. None of these things matter.

Sure. But if that's all you read then you don't see the big picture.

Perhaps this explains the focus on tiny details and missing the bigger picture. We all know about the importance of attention to detail. Of course the compiler spitting out two warnings rather than one here is imperfect. But it has no impact on any user. It's trivial. Delphi has so many big issues and this is what gets people heated?!

The complete lack of perspective here is breathtaking.

Leaving aside my sarcastic response above, I think a majority of Delphi users will not regard this as an issue. What happens here is that the compiler reaches a point where the errors which have been encountered so far mean that it decides to abort compilation of this unit. And it reports that decision as an error. It's been this way since the dawn of time. Nobody, but nobody, cares about precisely how many errors there are in their code. There are two states that matter: The code has no errors. The code has some errors. Were the compiler to do what you ask, and not write the "cannot compile unit" error, and report a single error, you would not know that there was but a single error. Because the compiler had given up and any errors that are present in the code which follows the point at which the compiler aborted, would not be counted. It is useful for the compiler to report counts of hints and warnings, since these values are meaningful. Counts of errors are, as I have shown above, are not. That this even has to be explained astounds me.

Modern C++ projection would be wondrous. Get rid of all those macros!

This is so important! We must leave no stone unturned in our battle to persuade Embarcadero to change this!

It's as if the thread above never happened!!!!

Unless you have a performance bottleneck, this is the shrewd approach.

assembly - How do I atomically move a 64bit value in x86 ASM? - Stack Overflow is also relevant

I'd read the documentation, which is here (E2217 Published field '%s' not a class or interface type (Delphi) - RAD Studio (embarcadero.com)) and which tells you what the problem is. There's a nuance here in that the section of the class declaration that does not specify visibility has published visibility in your environment. That's not always the case, I've forgotten what it depends upon, I think that there's a conditional. Anyway, the solution for you is to add the private keyword that it looks like you forgot, or deleted by mistake. Check in your revision control system. OK, and here's what I had forgotten. Again, I looked it up in the docs: Classes and Objects (Delphi) - RAD Studio (embarcadero.com) So you are clearly compiling the with {$M+}

What are you trying to do here? Are you trying to make an atomic assignment but ignore any race conditions? Where is the corresponding code that reads in an atomic fashion? No point having atomic writes if you don't pair them with atomic reads. You'll just suffer tearing on reading. For 64 bit code, reads and writes of aligned 64 bit values are already atomic. So plain Pascal assignment operators will do what you need. So long as your values are aligned. Can you be sure that they will be? Are local variables of type double aligned? It's quite an unusual thing to be doing, I know I've never had a need to do this with doubles. What is the motivation out of interest?

Multiple Document Interface - Win32 apps | Microsoft Docs In practice we can see that MS have not updated MDI for a very long time. The window chrome for MDI child windows does not match the latest style. I mean, this is MS, it's not going away any time soon.

If you want to submit a feature request to Embarcadero, do so here: https://quality.embarcadero.com/

Floating point values cannot be empty

A web search for this flag would tell you what you need to know. Always worth remembering that web search exists. I find it terribly useful.

The leak detection tool is known to work well. Please post on the madExcept forum. Applying Occam's Razor, you should entertain the possibility that there are defects in your program that this tool is notifying you of.

A minimal reproduction would make it simple to resolve the issue.

Bits not bytes. And not the most significant bits. The code runs on little endian machines.

This should be simple to resolve. Create a minimal program, including any input, so we can see what combination of rounding mode and input arguments lead to this exception.

It's copying three bytes of the ANSI encoded text into three bytes of the integer. The fourth byte of the integer is indeterminate, and could be anything. Just look up the ASCII table for those three letters, to see the ordinal values being assigned. It's hard to know why this would be done without seeing what happens next, e.g. to the integer variable.

What happens when you create a new project? Is it a problem with a new project?

You shouldn't be compiling that unit. Should find the dcu shipped with the product.

What is the error? Can you give a minimal reproduction?

What use is knowing that if your IDE won't start? Isn't the IDE not starting something of a bigger problem?