David Heffernan

Dude, we are talking about 64 bit code. You can't expect to make a 1GB array and do anything useful with it in a 32 bit process. Every chance that the virtual memory manager won't be able to find 1GB contiguous address space. This is virtual memory, and in 32 bit code usually the limits are from address space rather than physical memory.

Why? What is special about 1G?

Doubt usage was widespread

I already said. It's to avoid memory address space fragmentation when growing an array, even with the TList growth strategy. Address space fragmentation was a big issue when we had no 64 bit compiler. This is way beyond where you currently are. You need to fully understand how TList works first.

{$POINTERMATH ON} function TBlockAllocatedList<T>.GetItem(Index: Integer): P; var BlockIndex, ItemIndex: Cardinal; begin Assert(InRange(Index, 0, Count-1)); DivMod(Index, FItemsPerBlock, BlockIndex, ItemIndex); Result := P(FBlocks[BlockIndex]) + ItemIndex; end; {$POINTERMATH OFF} That's the key function in my implementation.

64 bit makes that problem go away.

I'm talking about an array like structure (i.e. O(1) random access, contiguous indices) whose backing allocation is not contiguous. I'm not aware of many (if any) collections in widespread use that are like this. I introduced such classes in my codebase in the bad old 32 bit days when address space fragmentation was killing me.

No it doesn't. It's just a wrapper for an array. Effectively it's the exact same data type but with a lot of helper methods to let you write higher level code. And an allocation strategy that overallocates to avoid performing heap allocation every time you add an item. I'm not sure that there are many collection libraries that implement array like collections as anything other than a contiguous array. I know my own personal code has some classes that do this, to avoid address space fragmentation. Less of a problem now that we have 64 bit.

How could it possibly know how many items were going to be added? In reality you often don't know this. I would not be surprised if your array code has lots of lines like SetLength(arr, Length(arr) + 1) which are hideously inefficient.

Read this closely. Here I say that I believe that XmlDoc is not suitable because you aren't doing library documentation for the library consumer. So we are on the same page. As I expect you know, my work is in the realm of scientific computing. In our case we are simulating the dynamics and loading of pipes and risers. We document the technical aspects outside the code, using LaTeX so that we can present formulae in a readable fashion. We then cross reference to that document from the code. This works fine for us. I think once you decide that you need formatted equations then that takes you to a separate document. Anyway, that's how we've settled on doing it.

Stop even trying to justify this. The two pieces of code are not comparable. You can see the single SetLength call. That's missing for the list. There's nothing more to say.

Actually the defect is in your test code. Set the capacity when you create the list. Just as you do with the array. Obviously you need to compare like with like.

Sometimes it should, sometimes not

Unification is good. Going to cause headaches for anybody with ARC only code. Don't think that's going to be an easy migration path. Such a shame that this happened at all, but good for Emba for having the strength to change direction.

You don't need to explain what your code is doing. The code ready tells you the what. XmlDoc is typically used to document libraries for the benefit of the consumer. But you seem to be talking about internal documention. I don't see what's wrong with judiciously used comments on the key methods. After all, the vast majority of methods need no internal documentation.

If you want your beta testers to find bugs, don't you want lots of testers?

I wasn't suggesting otherwise. I was just saying that my experience is with YAML, but the issues are essentially the same. You can't expect any system to be able to serialise arbitrary classes without some input from the coder.

I use YAML rather than JSON, with my own wrapper of libyaml. And I have written my own library to handle persistence, not RTTI based. I think you are always going to suffer if you let the standard JSON library try to do persistence for you based on RTTI.

Change the way you do JSON persistence then. Fix the real problem.

Ugh. Just use a generic list and scrap most of this duplicated code.

The most significant issue is that Set8087CW and SetMXCSR are not threadsafe. It's a bit of effort to fix it because you need to patch things like the code that handles external exceptions, which also interacts with fp unit control state. I wrote a comprehensive explanation of the issues, and how I addressed them. On request from Emba staff. I submitted that doc as a QC report. Emba then killed QC and asked me to resubmit all my disappeared QC reports. That pissed me off. Doc is here https://drive.google.com/file/d/0B2MV9dPR57BUbnVvNW0zaEFnYTg/view?usp=drivesdk

I submitted many QC reports, including one with a detailed document explaining how to make the floating point control word handling threadsafe. These got deleted when QC was killed. I can't be bothered to add them again. Marco and David M know about this.

True. But that's not necessarily less work. By batching a few releases together you reduce the number of context switches. That can easily be significant. If you do maintenence then you need to maintain a greater number of Delphi installations per dev machine if never skip. In my case I have to apply bespoke patch to rtl code to fix all the floating point defects that Emba won't fix. And that requires a chunk of work for every distinct version of Delphi. Skipping reduces that overhead. So blanket statements are easily seen to be bogus. It all depends on context.

OK, so you agree with me.

This makes no sense to me. You only deal with breaking changes if you keep current. You present an either or choice that's actually a both or neither!