David Heffernan

Remember that font glyphs are usually vector images and so rasterising into an image list may not be ideal, depending on your usage. My guess is that rasterising every glyph from a font ahead of time is terribly wasteful. You may run out of resources. Why don't you just draw each glyph on demand when you need to?

It will do because it knows the size of the fixed length array at compile time.

Evidence?

Same time for both versions for me, using 64 bit release build with XE7. I'm quite confident that your diagnosis is not correct.

In terms of accessing the memory, then there's basically no difference in performance between heap allocated and stack allocated arrays. The performance difference comes in allocation. If you are going to allocate such large arrays then the time spent working on them surely dwarfs the allocation cost. The other thing to note is that your stack is typically going to have a size much lower than the arrays you want to work with. So even if you could declare such huge arrays as fixed size, they won't fit I. The stack. In other words heap allocated dynamic arrays are the only option. Probably your next move is to revisit your benchmark and understand how you ended up with the erroneous view that heap allocated memory is slower.

No, I mean that linking C++ static libraries is exceptionally hard, because where do you get the runtime support from? No. It calls the standard Delphi MM. Also, there's no concept of freeing heap memory directly. That makes no sense. You always have to free from the same heap that was used to allocate.

Yes it's exceptionally hard. Just put the code in a DLL.

Would you like to trisect the angle with ruler and compass while you are it too? Seriously though, I wonder if it's realistic to look for a solution without actually changing anything.

In what version of Delphi is this? Are you sure that it raises an exception? If it does then that is a change of behaviour from the XE days.

Use an old version of Delphi that supports XP. Or give up supporting ancient versions of Windows.

Presumably it all depends on what is inside the try.

Really? Which architecture are you talking about?

Personally I think it's unrealistic to expect to be able to solve this problem without understanding it, but I can see why people might want to do that. Anyway, good luck with this, I hope it works out for you.

There are probably issues in your code that are the real problem here, rather than it being an issue with the VCL. But there are certainly issues with the VCL too. Whether they impact you it's not clear. Certainly trying to set the dpi awareness at runtime, based on the os or some other environmental factor, is not the right solution. This is a complicated subject that needs a lot of understanding from developers, and testing. There's probably quite a bit of work required from you to understand the issues with the subject, and your specific app. It might also be a good time to concentrate on supported Windows versions and stop worrying about the pre Windows 10 users.

I guess you know to use try/finally for this

Docs for GetComputerName say "A pointer to a buffer that receives the computer name or the cluster virtual server name. The buffer size should be large enough to contain MAX_COMPUTERNAME_LENGTH + 1 characters." You should do that. Use the constant in your code.

Wait until you have a bit more complexity and then you won't love it so much!

In reality you aren't going to have 32k forms. However as a general rule you don't want to be thinking about stuff like that. Just use Integer everywhere and avoid it being something to consider. Now, there are sometimes situations where a 64 bit loop variable is required but they are exceptional.

Never mind what the ide says. What does the compiler say?

You should use Integer for loop variables otherwise some day you'll be caught out with an unexpected overflow.

The biggest issue is the use of Smallint

The original question concerned code that called a constructor, then set a bunch of properties. I said, it may be better to pass that information as arguments to the constructor. I'm not proposing overloading anything. I feel that you are using a specific code style from your code base to make a general point that is not valid. I understand why you might have written a bunch of classes to be parameterless and then read state from a DB. But that's really specific to your code base. Why is it bad to pass arguments to constructors? I see absolutely no reason at all to make a blanket recommendation that constructors should not have parameters.

Who said anything about needing multiple overloaded constructors?

Hmm, not quite the same thing

If the information needs to be transmitted, it has to get there somehow.