Leaderboard

Threads are about parallel/background work, but after invoking a task, you could in theory use ITask.Wait to stop the main thread while waiting for it to complete - but then you might as well execute the code from the main thread instead of creating other threads. Also, if the thread gets stuck, your main thread would be stuck. It is better to use parallel threads and in the main thread receive signal events for when the background thread succeeds/completes/fails. Threads are not hard when you understand them and the best practices around the use of them - but gaining that knowledge can be a challenge. Read the theory, study the examples, and try it out.

I removed a couple of posts. Please stay on topic.

No. The order is undefined. For example, if you evaluate the expression (A and B and C ) the evaluation order might very well be BCA. Only boolean short circuit evaluation has a defined order.

You are right ! ... I've missed WIKI 🙂 https://github.com/neurolabusc/plyview/blob/master/mesh.pas LoadPly procedure for ASCII and BIN

No, because there are no parameters on ReadChar. No, because even if you mean the string concat method (which is UStrCat3 that will be called here) you will see that if you call ReadChar a third time suddenly order is correct (which then calls UStrCatN) No, because even parameter passing order is undefined behavior in Delphi

You can try to see if you find anything useful in this project. It can open and view various graphic formats (including "PLY"). It is possible that something is also exposed on pascal the "PLY" and not only in DLLs. https://sourceforge.net/projects/glscene/files/GLScene/GLScene v2.2/

Hybrid, Bastard, Chimera or (my personal favorite) Manticore. But as we already can call a function like a procedure, it may be straight forward to declare a procedure with a return type - even if there is no way to retrieve that value. 🤔 Looking into details, a function internally is just a procedure with an additional parameter for the return value. It is the declaration that makes the difference. After all, I agree that BlockRead/BlockWrite should no longer be used.

In the end, I had to abandon PUCU as the author never bothered to react to my bug reports. Instead, I tried to adapt the JEDI implementation: I removed all dependencies and fixed the worst bugs and performance issues. Finally, I ran the code against my unit tests. The result was a big disappointment; While it didn't crash like PUCU, it failed even more of the test cases. The test suite uses the 19,000 NFC (compose) and NFD (decompose) normalization test cases published by the Unicode consortium. So back to square one again. Comparing the algorithms used by the JEDI library against countless (I've looked at over a hundred) other Unicode libraries didn't reveal the cause. They all used the same algorithms. Blogs and articles that described the algorithm also matched what was being done. I was beginning to suspect that Unicode's own test cases were wrong, but then I finally got around to reading the actual Unicode specification where the rules and algorithms are described, and guess what - Apart from Unicode's own reference library and a few others, they're all doing it wrong. I have now implemented the normalization functions from scratch based on the Unicode v15 specs and all tests now pass. The functions can be found here, in case anyone needs them: https://gitlab.com/anders.bo.melander/pascaltype2/-/blob/master/Source/PascalType.Unicode.pas#L258 Note that while the functions implement both canonical (NFC/NFD) and compatible (NFKC/NFKD) normalization, only the canonical variants have been tested as they are the only ones I need.

FYI, you don't have to resort to that pointer hack if you enable the Writable Typed Constants compiler option.

@MikeZ87 sometimes you need to do a little "hack" ... if possible... look, StyleBook + Hacking class TComboListBox used by ComboBox in FMX ListBox using ItemHeight = 100 ComboBox using (ListBox) ItemHeight = 60 + colors

Every time I see allocations for comparing strings I have to cry