David Heffernan

Those libraries will be appallingly slow. In terms of the calculation side of it, it doesn't sound like you have a problem. Use double. As far as the IDE goes its not surprising that a program written using the Delphi rtl doesn't convert floats to decimal text correctly because the rtl doesn't. Or vice versa. Never has done and in spite of Emba being told more than a decade ago they haven't shown any inclination to address it. In my code I use dtoa and dragon4 to do these things so I can get correct values.

I'm not talking about generalities. I'm talking about this specific topic. The OP already said that the pointer values that are streamed are ignored. The problem at hand is that the code does naive blitting of internal records, and these records have different layouts for different targets.

What would offsets be helpful for given that the data streamed in those fields is never used

Not in IEEE 754 floating point data types that you are using. Anyway I'm not actually sure what your actual problem is. Do you feel that there is an issue with the debugger? As for 80 bit floats I don't see any future for them. That idea died and everyone uses 64 bit double now. Is double insufficient for your needs?

Streaming offsets doesn't seem helpful. The user isn't interested in streaming addresses. The addresses are initialised at runtime. They are only streamed because the code is, er, sloppy, and blits raw records rather than serialising.

Are you running your IDE elevated?

I'm just curious but why are you using AnsiString casts which produce behaviour dependent on the executing process locale? Did you mean to encode as UTF8?

But what is the problem? You can't solve something until you know what the problem is. As Lars says, streaming pointers seems, er, pointless.

Surely this could be done using regular expressions

When performance is an issue, pass by reference then. Presumably you are happy to use value types like integer? Or do you shun all value types? Prevent what bugs? Code with interfaces can have bugs too. So it's not some magic solution. Code using interfaces can have leaks. They are still there, the compiler writes them. It's the exact same pattern as used with classes. It's well known and easy to follow. This is true. But it's simple enough to flow the rules and avoid this.

So what would be the problem with that? That's what happens with vakue types. Why would interfaces be needed to avoid memory leaks?

Actually, I think that this was the first mention of GetMem in the thread.

Problem with this is that if the record has any managed types, then they won't be properly initialised/finalised when using GetMem/FreeMem. This is what New/Dispose brings.

This looks like a compiler bug to me. not(a) or True should be the same as: not a or True which in turn is the same as: (not a) or True because unary not has a higher precedence than or. See Expressions (Delphi) - RAD Studio (embarcadero.com) I can't see why your code should fail. I suggest that you submit a bug report to Quality Portal.

That's been possible for years

I opened Visual Studio the other day and made some edits to a C# module that implements an API interface for our software. We have interfaces in a variety of languages, C++, Python, C#, etc. I was blown away when VS offered me suggestions for the code I was writing. Clearly it's using some AI library to do this. Honestly, the quality of the suggested code blew my mind. I knew what I wanted to write, and so did VS. This is only going to get better and better, but it's already amazing. So far as I know, there's nothing remotely like this for us Delphi users. Or would we get this is we wrote our code in an editor like VS Code??

I had hope based on my QC reports from XE7 days. In any case it's a huge design mistake for Emba to implement windows themed menus as custom draw. Just let the bloody system draw it and then it will always be right!! Well, MDI excluded, but menus are getting deprecated any time soon.

I never submitted any.

Ha ha ha. I think we all know the answer to this. They can't even do menus properly. Even for the standard windows theme the menus are custom drawn and the Emba code gets it wrong in various mixed dpi scenarios. When I switched to Delphi 11.3 I'd hoped to avoid having to patch the VCL to suppress its custom drawn menus. Alas that hope was doomed.

That's fair. But it's not the subject of this discussion.

The two versions are identical, apart from the double dereference with the class wrapper version. That's the only part that seems ugly to me.

This is correct. Raw pointer in C++ is directly analogous to typer pointer in Delphi. However a reference to a class instance is actually no different from a raw pointer. You have to manage allocation and deallocation of both. Which is my point.

How is this materially different? You still need to explicitly Free, and you need try/finally. The class is just extra baggage. For what gain?

That's what I thought. What about the part that pointed out the futility of setting the flag without having the corresponding compiler support?