Mike Torrettinni

Makes sense, I guess I should get rid of old utility units, that were needed in old Delphi and might not be anymore. I'd start with all platforms in a single unit but split it as you do if it grows larger This fits into my projects, or a combination, so makes sense to start slow and split if needed. Some units I know will have to be Windows only, so I will split the from the start.

I just managed to get 'hello' on Linux 🙂 First time Linux user! so it was a bit intimidating, but with help of Marco's video and google I managed to get it working. First time using the famous sudo command 🙂

Well, in those cases +1 is used, but all those cases are for up to 10 records, mostly. Not sure where are you going with the questions?

Yes I have a few, but not in loops. A few places I found are used like this in simple reports when it's just a few lines, like report headers or category selection views. Not in the loading, parsing... heavy data manipulating methods. But I had plenty of these when I started, so many years ago 🙂

Yes, I agree. Well, now that I see lists are not that much better at memory consumption compared to arrays, I don't know, will have to try and see what I'm comfortable with. I've been using array for so long, it's hard to switch. Thanks.

So, you are saying I can have more than 4GB in one (or more) arrays in 64bit project, even if customer has 4GB memory installed? If yes, then this is awesome news! I know optimization is very good, but sometimes it can be just overkill, especially when dealing with large log or data files - and without memory restrictions in 64bit, I could save time optimizing memory consumption to something more useful.

Yes, probably I will get to the similar limit even in 64bit code, if customer has 4GB memory. But in this case, its easier to upgrade memory and all is good. So, I guess 64bit will make it easier on large arrays or lists (now that I know they consume similar/same memory size 🙂 )

Aha, expand, I missed it the first time. My example above is not good then.

I can easily create single array that exceeds 1GB: using {$SETPEFLAGS IMAGE_FILE_LARGE_ADDRESS_AWARE} even bigger single array: 32 bit project.

Thanks.

David, if you are up for some details... can you explain the context on which you decided to use this approach? What did it help solve and what advantage does it give you.. is it memory consumption or something else? Do you build such blocks of data once and just access it through the life of application? Do you use it for simple types, complex records or both and works good?

I agree, less of a problem, not without it completely. I was thinking for may years that 64bit will solve my memory issues... then I realized that many customers don't have 32GB, some are OK with just 4GB of memory.

Thanks, interesting. All disadvantages aside, it would solve many Out of memory errors, when it's getting close to limit, but only goes over because of the need for contiguous block.

This is actually strange realization, right now... seems useful, if it would be like that. I use similar approach in showing data in Virtual Treeview, where records can be added at the end of the array, while displayed as sub node of 1st node - dynamic tree generations, I guess.

I thought that TList has the benefit over array because it doesn't need a contiguous memory block to keep data. Array needs it, while TList keeps a list of pointers to memory where it stores data, so it just finds next available free space and never needs a contiguous block. I guess it doesn't work that way.

Just wanted to share with you how I finally made SetLength work with Generics 🙂 Across all my projects, I use a lot of arrays, a lot! started with Array of, now slowly converting all to TArray and even slower started using TList for some cases. So, in all my methods I use the common way to increase size of array - when adding records: if vIndex > High(DataArray) then SetLength(DataArray, NewLength); This means I had this in all the methods... a lot of arrays = a lot of methods = a lot of SetLength calls. So, then I started setting methods so I reduced 2 lines into 1 line, with: procedure DataSize(var aDataArray: TArray<>; aIndex: integer); begin if aIndex > High(aDataArray) then SetLength(aDataArray, NewLength); end; and calling in all methods : DataSize(DataArray, vIndex); So, this was a progress. And I liked it a lot! Then it progressed to having all DataSize procedures for all kinds of record types, overloaded. Even better! And now I finally was able to take time and try with Generics, and this is what I have now: TArray = class(System.Generics.Collections.TArray) private class function NewSize(aCurrLength: integer): integer; // seperate function so I can manipulate how the New Length is calculated public class procedure DataSize<T>(var aData: TArray<T>; aIndex: integer); end; const cFactor = 1.2; // increase by 20% class function TArray.NewSize(aCurrLength: integer): integer; begin Result := Ceil(aCurrLength * cFactor); end; class procedure TArray.DataSize<T>(var aData: TArray<T>; aIndex: integer); begin if aIndex > High(aData) then SetLength(aData, NewSize(Length(aData))); end; The call is a bit ugly, since you have to use TArray. I only used it a few times, so far, so I'm not complaining, yet: TArray.DataSize<TRecLine>(Data, vIdx); These Generics are pretty good! 😉

Thanks! By setting Capacity (vDataList.Capacity := vMax;) I can make it work as efficient as TArray. I was under impression TList has this magical power of handling with memory, I guess it still needs a little help here and there.

I always add data with assigning values directly: SetLength(Data, StartLen); // prepare vIdx := 0; // add records to Data for i := a to b do begin TArray.DataSize<TRecLine>(Data, vIdx); Data[vIdx].Id := ...; Data[vIdx].Str := ...; Inc(vIdx); end; SetLength(Data, vIdx); // finalize

Thanks, good to know and makes sense! I just thought how boring it will be when I become 'expert, so maybe I shouldn't 😉 Well, good to know it never gets boring and always some challenging stuff to do.

By now you should know I'm in some sort of denial (especially when it comes how much dev books I should read) 😉 I didn't want to hijack this thread, but as always I will get something out these debates, even though I got a little triggered by some comments. I'm just releasing new software and I will rethink the whole Range on/off in release version. Thanks!

Well, imagine you have analytical feature that analysis 1000s of data connection points. And the results just give you the sense of connections between data, so if it shows 499 instead of 500 connections is not such a big deal. If it shows only 1 instead of 2, could be huge issue since it's missing 50% of the results, or you are actually expecting the 2 and you report that 1 is missing. And let's say you are browsing though 10s of data objects with the connections to get the broad view of the connections. In this case it would be extremely annoying if the first example (499 out of 500) would block the whole usability. of the tool until bug is fixed. So, screenshots and detailed description is usually enough to track down and fix the issue.

In perfect world, there would be no 'idiot' developers who can't handle exceptions correctly. But we all have used software where approximation, 'as best as possible' or 'good enough' is used. Just think of any diff tools (do they always show 100% correct difference or line alignment?), any drawing tools (have you ever checked if pixels are 100% correct if doing something a little more than basic stuff) and so on... error messages in such cases would be absurd. Of course, as mentioned, some software like accounting should be 100% correct. I guess my customers prefer reporting incorrect results vs error messages, so Range checking is off in release version.

I also set Optimization Off, Range and Overflow On, in debug. But for release, of course Range is off. But I see some of you set it On also in release mode. I only sometimes set them on for Beta versions, never in final release. I would rather have wrong results reported by users (and then I see that Range On would catch a bug and I fix it) vs to trigger exception to the customer. Perhaps this differs if you project is used in house vs out of country customers.

Same experience here, it seemed half-bold and a little bit fuzzy, on my screen.

I tried Ubuntu Mono and Jetbrains Mono (at sizes 9 and 10) for a couple of hours each, and Source Code Pro at size 9 still best, in Delphi white theme. Monitor: 24", 1920x1200.