David Heffernan

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?

You are searching with the "regular expressions" check box enabled, hence the message

Hmm, sucks to be you rn!!

This sounds like a pretty unfortunate design choice. But since your compiler knows the layout of those records you can just work with the record types and the compiler takes care of the layout.

It's actually very easy to predict this, once you know the rules. There is a good reason. Instead of ranting, maybe you should assume that the people that designed this knew what they were doing and that you just don't understand it. The question I have for you, is why are you so interested in size and layout of the records. What is motivating your interest. That might be helpful for us to understand.

I have routines to do that. Because the Delphi code to convert between text and floats is irredeemably broken. I'm using dragon4 for float to text, but these days there are better algorithms around. I use dtoa in the other direction. My code base is spewing out a lot of floats to text files and yes it makes a significant difference to performance. Especially for files on a local drive.

Kind of irrelevant whether it's heap or stack. Just that you avoid the heap allocation.

The funny thing here, to my mind, is that I'd have expected that the first thing you did would have been to replace the actual function with a pointless work tasks that span in a loop for a certain period of time. If you then found that the behaviour was the same, i.e. not using all processor resources, you would know that the issue was in the library, or how you were using it. In fact had that been the case you could have come up with a very short example to capture the behaviour. You'd probably then have had an answer in an hour or two.

Yes, this is it. It's a very important use case though. Imagine writing large YAML or JSON files containing a lot of data. And then imagine trying to do the same with multiple threads with extra contention on a memory manager. The point is that you build IntToStr using a function like mine above. And publish both. This allows the consumer of the library to have both options. Even if avoiding heap allocation is something that is only done in a narrow set of circumstances, that doesn't render it unnecessary.

I guess all the software that I've released in recent times didn't happen because I was using a useless tool.