David Heffernan

I mean, you were the one with the headaches.

I'm struggling to imagine what headaches would be solved by this feature. I don't know how you can't get a list of generated files by simply checking out the project and then compiling it. All the files created after you compiled are the ones made by that compile.

FYI this appears to be cross-posted here: playsound - How can I play quick sounds in Delphi? - Stack Overflow

There's plenty of reasons not to use AnsiString, unless the library is not developed any more.

I mean, byte arrays exist in Delphi 7

On modern delphi you can't get away with this as has been discussed many times. Anyway just because people got things wrong 20 years ago is no reason to continue getting things wrong.

I was referring to base64. That takes binary input (so bytes) and outputs text (so string). For sha1 the yes the input and output should be binary, that is bytes. The you'd have helper functions to take hash output and write in friendly hex format. At no point should there be AnsiString. I mean I hope you aren't proposing AnsiString as a place to hold bytes.

It makes no sense to me that a base64 function could ever accept string input. Input base to be bytes. This is also kinda weird. Shouldn't it be the native type for text, string.

Massive performance hit compared to double on 64 bit

Floating-point arithmetic - Wikipedia

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.