David Heffernan

The hardware is designed to handle indexed access efficiently. I've seen plenty of cases where incrementing a pointer inside the loop is slower. After all, you have an extra variable that needs to be incremented. Hard to see why that would be faster. No. The memory access pattern is identical. It's just a sequential pass across the array.

The two 0b characters are valid UTF-8 characters. They are this character: https://www.fileformat.info/info/unicode/char/000b/index.htm What you need to do is decide exactly what your specification is. The question you have asked doesn't seem to match the example you have provided.

Not necessarily. And in any case, if you wanted performance, you'd not have chosen Delphi.

This is why I always implement my enumerators as records so that they can be automatically allocated. Will it? Faster than array indexing? That seems to be something of a myth in my experience.

Correct.

Loop variables are assigned using assignment semantics. That's all you need to know.

It's the same issue for both types of for loops. The value of the loop variable is undefined if the for loop terminates normally. In your case that corresponds to the condition never having been met. Unfortunately though, whilst you are aware that there is an issue here, you have not correctly understood what the issue is. That reasoning is incorrect. The loop variable i does not change in case of a normal termination, e.g. the break in your code. Before you consider for in loops I recommend that you correct your misunderstanding of for loops. Executive summary. There is an issue with for loops of both kind. It is the same issue for both kind of for loop. But the issue is not what you have described.

Define what you mean by a non UTF8 character, remembering that this is a variable width encoding.

Why are you cross posting? https://stackoverflow.com/questions/64010603/delphi-getting-stream-read-error-on-really-simple-program At every site where you cross post, potentially different people will provide you the answer. Which means that more people than necessary spend time on this. As a broad rule, people who provide this sort of help don't appreciate this kind of behaviour.

DELETED: because it was nonsense

This is the correct way to do this. It works fine. The problem is elsewhere. Don't create and raise a new exception.

Packing does make a difference here. It may not change the layout, but it changes the alignment of the type.

No it shouldn't be declared as packed. The structure, as is invariably the case for Windows structures, should be aligned.

Nobody can diagnose the problem without seeing your code. Once you show us a minimal complete reproduction then it will be straightforward to explain the behaviour of your program.

That trade off depends on the size of the record. For small records then performance is better if the items are stored directly in a contiguous array.

OK, this is making more sense to me, and I can better appreciate the inconvenience.

Maybe. I guess I might not be encountering the problem regularly. You must be facing it very regularly I guess. Isn't that a different issue?

You are massively overstating this. Finding a file from disk is not difficult. Yes it takes a few seconds, but then it's not like this issue happens regularly. Every feature takes resources to implement. Given the immense problems that the entire Delphi product has, I for one would be disappointed if Emba spent resources on features like this that bring so little benefit.

Doesn't seem to me like this is a very significant problem given that you can just open the file in a text editor yourself.

Not sure the IDE should do that. There are tools to convert. If you want to convert, then use those tools. If the IDE did this automatically then that would be painful for people who wanted to use binary.

If it is in binary form then presumably there would be no need because there would be no problem in it

Well, you avoid some of the issues, but not all. For instance you don't avoid the issue where an item is deleted, but a stale pointer is retained. Additionally you end up with a large number of heap allocations, and memory that can be scattered which can impact performance.

Granted the indirection that is offered by a reference type does make some of the issues hard to trip over, but they still exist.

In a collection which owns its members then removing an item leads to a stale reference in either scenario (classes vs records).

Your third sentence directly contradicts the first sentence.