David Heffernan

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.

53 minutes ago, Sherlock said:

So actually, while looking cool and trendy it really is slow and not so cool at all?

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

19 minutes ago, Fr0sT.Brutal said:

for-in means creating iterator

This is why I always implement my enumerators as records so that they can be automatically allocated.

19 minutes ago, Fr0sT.Brutal said:

Anyway if speed is important, pointer-based iteration probably will be faster

Will it? Faster than array indexing? That seems to be something of a myth in my experience.

8 minutes ago, Lars Fosdal said:

So, looping an array of records using for v in array, can be significantly more expensive than indexed access using for vx := Low(array) to High(array), given the size of the record?

Correct. 

55 minutes ago, Lars Fosdal said:

I have not really thought about how the variable of a for in loop over an array of records is kept.
Do we see a deep copy of the array element in the loop variable, or is there pointer magic involved?
I can see how this could be a problem if the reference passed is to a local stack copy.

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. 

1 hour ago, Mike Torrettinni said:

I never rely on i being the same value after loop as when 'condition' is met, so I assign i value to variable (vIndex)  so I can use the value of i  after the loop

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

2 hours ago, Dany Marmur said:

So ... this gives an AV:

      on E: Exception do
      begin
        LogErrors(E, SessionID, UserName, UserID);
        raise;  // AV Here
      end;

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

On 9/18/2020 at 9:03 AM, Uwe Raabe said:

As all fields in that record are either 32 or 64 bit (depending on the target platform) it doesn't matter if the record were declared as packed or not.

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

On 9/18/2020 at 7:36 AM, Der schöne Günther said:

Not sure if the record should also be packed. Personally, I would add it, but the declaration from Winapi.Windows.pas is also omitting it.

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.  

4 minutes ago, Fr0sT.Brutal said:

As for allocations, they're not so massive and quite acceptable compared to array-of-large-blocks allocations and moves when the list is sorted.

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.

27 minutes ago, dummzeuch said:

I'm encountering this problem regularly when some component isn't installed in the IDE or is installed but in a different (usually older) version. It would be nice to simply open that dfm as text and be able to make rudimentary changes to it. Most of the time it is enough to remove or change some properties from the dfm to make it load normally. The IDE always offers to delete a property or control, but I don't trust it (and I have reasons for that).

Currently I open the dfm in a text editor but that's rather inconvenient.

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

26 minutes ago, Memnarch said:

You are massively underestimating this 😛

Maybe. I guess I might not be encountering the problem regularly. You must be facing it very regularly I guess. 

28 minutes ago, Memnarch said:

If you refactor a base component other visual components dervive from, loading/opening projects might fail. I support the Idea that the ide still loads the dfm as text. Right now it does not allow me to look at it, which is cumbersome. Just like WPF in VS where I always get the XAML editor but not a visual editor when the XAML is invalid.

Isn't that a different issue? 

18 minutes ago, Tommi Prami said:

And find file from disk and the spot, sure diff to repo will help, but still, would be life saver when this happens. 

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.

53 minutes ago, Tommi Prami said:

Vote if you care : https://quality.embarcadero.com/browse/RSP-30991
IDE Could/Should open dfm in text form, if it/RLINK will find some problem with it. (and show the position in way or other)

 

-Tee-

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.

6 minutes ago, Tommi Prami said:

Would be nice IDE would always convert binary to text, if there are one. Got hit by that this summer, there still was few binay dfm's in our repository.

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.

8 minutes ago, toms said:

Convert it then?

https://stackoverflow.com/questions/3494554/delphi-form-dfm-to-text/3496617#3496617

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

1 hour ago, Fr0sT.Brutal said:

Ah yes right I haven't noticed the getter returning pointer to array item. In my record list class I use dynamically allocated records and store pointers only so have no such issues.

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.

1 hour ago, Uwe Raabe said:

If I got that right, Stefan is referring to the case where the array is relocated, which invalidates the record pointers. This is not the case for a class list, where only pointers to the class instances are stored inside the array. Relocating such an array will keep the instance pointers intact.

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

1 hour ago, Stefan Glienke said:

Nope - with classes you are dealing with reference types - in this case you are pointing to a location inside the dynamic array being used as storage inside the list - any reallocation can change that.

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

55 minutes ago, Remy Lebeau said:

The RTL's generic TList<T> does not provide access to elements by reference, only by value.  At least for its Items[] property.  Its List property gives you access to the underlying dynamic array, so you can access the elements directly.

 

Your third sentence directly contradicts the first sentence. 

14 minutes ago, Stefan Glienke said:

And there the trouble starts - why on earth should the byref property be writeable.

Yes, this should be a read only property.

In an ideal world we'd have proper language support for references, as I think is especially we done in D

foreach (ref elem; arr) {
    elem = 0;
}