Mike Torrettinni

I find this very valuable! I was only checking commits at the beginning, learning git and git tools, then I stopped - I believed if feature is done and it compiles it should be ready for commit. Well, after reading this statement, I started checking the changes about to be committed, and soon I noticed that when working on multiple units I forgot to delete debugging or temp stuff. Or I noticed something is implemented odd and should be improved, something I wasn't focused on at the dev time.

I really like the unit scope naming, it organizes source files, I can much quicker find needed unit... but the annoying thing is how IDE is handling these long named units. Here is example of MARS project and how only a few units are shown without scrolling: Is it possible for IDE to show all opened units in multiple lines (2+) if not all units fit into 1 line?

Nice! Is it ready to be shared? How do you invoke it, Ctrl+Tab?

I thought those were just screenshots, mockup suggestions.

I did look at the CtrlTab plugin at the beginning, when it was released, but didn't really find it useful. Testing now for a little bit and I do see it being useful. 🙂

I know about the drop-down list, but didn't know about Ctrl+F12. Even though I have project manage opened almost non-stop, once the number of units is high, this Ctrl+F12 could be useful.

I'm testing CtrlTab plugin and seems good alternative.

Great plugin @santiago! Small Suggestion: Show/identify which units have been changed, like IDE does: Maybe something like this:

I found example in Visual studio, even thought it looks bad, when you need to have all these units opened, you are working with them and you want to be able to switch fast between them: That would be nice to have option in Delphi IDE.

Well, if there were 2 lines so you can see all opened units, it's a very quick mouse move and click to show that wanted unit. Every other option involves scrolling or opening a list (or a DelphiCtrlTab view) and select unit, no comparable at all.

I know I should never rely on iterator value to be kept as iterated value when normal For loop ends, but what about in For in loop? 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: for i := 1 to n do if condition then begin vIndex := i; Break; end; But in For..in loop I assume vItem still holds the same value as when condition is met, so I can use vItem afer loop for vItem in Items do if condition then Break; All my tests show that vItem keeps the value and can be used after For...in loop. Am I right and I can use vItem without worries, or is there a case where vItem should not be expected to be the same value as when 'condition' is met?

Yes. I have a situaition where initial simple structure has become quite extended with nested records. So, what seemed at the beginning a very elegant solution with For..in, is now becoming a little slower due to more complex structure and more extensive use. and I don't want to risk this to be performance hog for large customers (high number of records). I have decided to stop using For..in, so when I code I don't need to think about it. Now I have good reason to stick with 1 style. Except if I will open source anything, that's when I see a For..in looks much better.

Useful, but not really helpful for this case.

I was referring to variable iterating For..in loop - in this case full array record content is copied into variable. No? At least that's what I see from the simple example above.

Iterating a few large records (390MB) or lots of small records (10000x 0.039MB), could have similar performance effects.

If the iteration is the only thing that is affected with such large records, then is good to know what could be performance bottleneck. I don't have any records of such size, so it is good to see what happens if you have nested records of large size, or smaller records but you have a large number of them, so iteration copies smaller memory but a lot of times - could be even worse than a few of 390MB records.

In this simple example you can see the the memory consumption jump when starting to iterate and also the time it takes to copy each record (not too much, but noticeable under debugger): The memory consumption of each record is around 390MB so the effect of iterating with variable is very noticeable, while normal iterator is fast and no additional memory consumption: const cMaxItems = 100000000; type TData = record Values: array[1..cMaxItems] of string; end; var gData: TArray<TData>; vItem: TData; procedure TForm2.FormCreate(Sender: TObject); var c: integer; begin SetLength(gData, 3); gData[0].Values[1] := 'a'; gData[1].Values[1] := 'b'; gData[2].Values[1] := 'c'; for vItem in gData do // slow and watch task manager for memory consumption inc(c); for c := Low(gData) to High(gData) do // fast sleep(0); end;

You guys are right, it really creates the whole record structure for variable iterator and copies the content, for each item iteration. So, if you have really big record structure it will use some memory, or will be considerably slower than using normal iterator. Had a suspicion on this, but never really thought about it enough (or test it myself), but now I know for sure. Thanks, I had a feeling is good to check with experts or read the documentation 🙂

This is probably very subjective, but I'm just trying to get another view/thoughts on this example: when adding simple records (not a lot of lines of code), I used to always use 1st example, DataSave1: use boolean flag and add new if record not exsits, but lately I try using Exit, like in 2nd example, DataSave2: - update record and Exit, flow never gets to adding new record: procedure SaveData1(aID: Integer; const aName: string); var i: Integer; vExists: boolean; vNewData: TDataRec; begin vExists := false; for i := Low(Data) to High(Data) do if Data[i].DataID = aID then begin Data[i].DataName := aName; vExists := True; Break; end; // Save new Data rec, if ID not found if Not vExists then begin vNewData := Default(TDataRec); vNewData.DataID := aID; vNewData.DataName := aName; Data := Data + [vNewData]; end; end; or without boolean flag: procedure SaveData2(aID: Integer; const aName: string); var i: Integer; vNewData: TDataRec; begin for i := Low(Data) to High(Data) do if Data[i].DataID = aID then begin Data[i].DataName := aName; Exit; end; // Save new Data rec, if ID not found vNewData := Default(TDataRec); vNewData.DataID := aID; vNewData.DataName := aName; Data := Data + [vNewData]; end; I like 2nd example because I don't need vExists flag. Am I setting myself up to some unknown issue that I can't see? These are examples for small Data arrays. type TDataRec = record DataID: integer; DataName: string; end; var Data: TArray<TDataRec>;

One last follow up question: do you add these IndexOf*, Find*, AddNew*... methods on all records or just important arrays, lists? I assume you don't make these methods for temporary or records not exposed to outside of a feature or unit, right?

Great, thank you for all the suggestions! Got a lot to think about.

You packed a lot of information into this and I'm a little lost, could you just show example how you set up your if .. then or if .. then .. else?

Seems pretty useful! In case a record has 2 (or more) unique identifiers... like ID and ProjectId, would you then have: EnsureRecord(ProjectID, ID) ? Or I misunderstood the concept?

Different record structures, from a few to nested records, why is this important? Hm, actually not sure are you asking about how many records in Data or elements in TDataRec?

I use Exit a lot as 'early exit' on conditions, but those are usually simple and very obvious statements at the beginning of the methods. Not sure in which version it was introduced, but I like how Exit is marked with a red arrow (you can't miss it):