David Heffernan

Unfortunately Emba never implemented proper generics support for sets which would make this trivial and type safe.

The issue is that you need to write this code for every single set type that you use.

There is another issue here, which is that you check bits that are unused, it the base type has number of members not divisible by 8. Probably you get away with it because it's probably hard to get 1 in any of the unused bits in a set.

Thinking again, the specifics are important here, the use of an untyped parameter that is overload with an absolute variable. This basically renders range checking close to useless, because of the unsafe typecast.

That's wrong. The code reads absolute aSet rather than absolute aByte. Consequently this statement is also incorrect. aSet could be on the stack, or the heap, or a global. In any case, I took the question a bit more generally than you. Accessing arrays out of bounds can lead to AVs or corruption of other memory in the case of a write operation. Yes, I know that the example here is a read. I was generalising.

Behaviour is undefined. You might get an AV, or a write might corrupt data. Definitely not graceful failure.

Your code doesn't load a dll. You have an abstract virtual method that is never implemented. You are trying to run before you can walk. You aren't going to learn anything useful this way. You need to go back to the basics.

Enumerate the members of interest and persist them. If these classes are really that simple, what is the difficulty? What are you stuck with? Using the RTTI? Or working with INI files?

Talk to other people and see what they want.

This was from the original post. I suspect you meant to say fragmented rather than defragmented. When I asked how you assessed fragmentation you said that you hadn't, and that you didn't understand virtual memory. I don't know what you think you have demonstrated, but I don't think you have demonstrated anything at all.

What's the point? You've already reached a false conclusion based on a flawed investigation. If we try to point this out you tell us that you aren't interested in learning the truth.

Why aren't you curious to learn about how virtual memory works? Why aren't you curious to learn how sub-allocating memory managers work? Why aren't you curious to learn what address space fragmentation is?

I understand that you'd like that conclusion. It would be nice if it were true though. It isn't.

If you don't know about address space fragmentation, don't you wonder whether or not it is relevant?

Are you measuring address space fragmentation?

It's just calling methods and accessing attributes. No different for pandas than for any other library.

Delphi's memory manager is fastmm. Also, your tool to measure the effect of the program isn't really telling you anything. It says nothing about fragmentation of address space. Virtual memory is a very complex subject. I suspect you need to learn more of the details before you can reason about your program.

Seems a bit needy

Agreed. Why would the main form destroy itself before the code in the dpr completes?

There are lots of posts on this topic on the madExcept forum. Websearch with the obvious search terms will find them.

You seem to be wanting to change your program, but now you tell us that you can't change it. Seems like a waste of time.

If you can't change anything, I wonder what this topic is about. Is it a thought experiment?

You don't need to change them. You just need new versions of your existing glyphs.. You'll need to hire a graphic designer.

You need to spend some time and establish some basic facts. We can't give you meaningful help on this basis.

Clearly you have got some code. The code is what you are trying to compile. The error message tells you what line of code causes the error. If it used to compile, something changed. What?