David Heffernan

It's kinda lame that they still haven't addressed this. It's been an issue since Delphi 1. The tech exists. They can already dynamically load and unload packages.

This seems like a much better approach to me. And as soon as you have to deal with different versions of a library, then aren't you forced this route?

You have different SVG files for different icon sizes in some cases?

But scalable doesn't tend to be right for icons because you often want to tailor the icon to the size. So a small version of the icon might have quote different content from a large version.

I don't think SVG is the right way to handle scaling of icons. Why do you think that?

I don't. I skip that step where you reinstall Windows!

Well, yes. That's part of the contract. SetLength is contracted to return a unique object, that is with ref count 1. It's even documented! http://docwiki.embarcadero.com/Libraries/en/System.SetLength "Following a call to SetLength, S is guaranteed to reference a unique string or array -- that is, a string or array with a reference count of one.“ The only scenario you've raised that I could see being troublesome is a copy for weak refs. Everything else isn't going to have discernible real world impact.

I'm just saying that it's very unlikely that there will be real world code that suffers. That said, I don't know about weak refs so that could be significant.

OK, so no copy, and not much else, unless it's a jagged array or has weak refs.

It was you that referred to jagged arrays. Once you start using them, for rectangular data, you've given up caring about performance. I didn't see any copying when I looked at this. I don't see any evidence that performance is a significant issue here.

I wouldn't overplay this. Jagged arrays have terrible performance. Your problem is not that all these ReallocMems can be skipped, but aren't. Your problem is that you are using a jagged array rather than a multidimensional array. Your problem is that you did 101 allocations (not 1000) rather than 1.

It's just a realloc of a block the same size, which is a null op and nothing happens. Unless you have a pathologically insane memory manager. But no memory manager I know of would do anything other than null op for this realloc.

But, at the end, do you, or do you not, end up with an array that is the correct length, and respects the contents that existed before you called SetLength? If perhaps you are worried that there is a performance hit, measure it. I can't believe we would still be having this debate about premature optimisation. You remember us mentioning this to you before? If you want to make your code run faster, why don't you optimise the parts that take the most time?

Why would a check be needed? What is the defect that you are claiming because there is no check?

What difference would that make?

I'm struggling to appreciate what the problem is. I don't think SetLength behaves incorrectly. Am I missing something?

This could be pretty expensive if the task is short lived. As a general rule, the owner of the thread should take charge of initialising COM. In this case it's probably the thread pool. I'd be looking for a feature of the threadpool whereby the client could request that threads created by the thread pool come initialised for COM. Then the initialisation can happen once for each thread, rather than for each task.

The months between now and a fixed date in the future do have known numbers of days.

^^^ this

I think this desire to prefix everything is not helpful. I can't see what you are gaining by doing it. And doing so introduces a risk that you will read meaning into something that the compiler does not. Which means that if you ever forget to use your chosen prefix, or use a variable defined in a unit outside your control, you might infer the wrong thing. I personally use F for fields, and T for types, and nothing else. I use F for fields to avoid a clash with properties. I think the language design pretty much forces us to do that. As for types, that's more of a historical choice. I think if I didn't already have a heap of code written that way. Wouldn't your time be better spent improving your code rather than agonising of which letter to use as a prefix? If you decide to prefix your names, then pick a system and stick to it. It doesn't matter which letters you choose!

I don't think that's a very helpful way to think about it. I would reserve the term local for a variable declared inside the body of a procedure. This includes any by value parameters. There are two main aspects at play here: lifetime and visibility. A local variable, as defined above, is created when the procedure is called and destroyed when the procedure returns. This is a narrow time frame of life, worth of the term local. A variable declared in a unit is created when the program starts and destroyed when it ends. That is a far wider time frame, and the term local is, in my view, ot befitting such a thing.

Every question you've asked in this thread has been answered now.

Do you do it for a reason? Surely these things should be intentional.

Why do variable names need a prefix?

@Remy read up to the part where all this happens in another process with, presumably, ReadProcessMemory.