Leaderboard

The question stands - there is no "yes/no" about that - their reference count is threadsafe - an assignment is not because its not atomic (which is the very same issue that Dalija wrote about in her blog post). About this discussion I think it is nonsense - the issue being pointed out by Marco arises when you access something with a broader scope than where you are currently - i.e. a global variable or a variable outside of the current nested routine - that also includes passing the same variable by reference twice or more and modifying it. f(i,i) would also be defect if it was implemented like this: while a > 0 do begin Inc(b); Dec(a); end; "Better" for strings would raise the question: better for what? Memory consumption? UTF8, string interning. Multithreading? Immutability. Memory locality? Short string optimization (i.e. avoiding the memory indirection) - there are probably more and most of them would be a complete breaking change even more than Delphi 2009.

You've had my suggestion. Use a boolean and give your function a good name. Where you can't do that, use an enumerated type. You seem to be looking for problems where none exist. These kind of problems don't need to be fixed!

Should have been titled "In Which I Argue that Embarcadero Should Write Their Unit Tests".

After doing a lot of SQL, I find myself wanting to name parameters in Delphi too... TFileSearcher.FindFiles('c:\', aRecursive := True);

You mean something like TFileSearcher.FindFiles('c:\', TFileSearcher.TFindFilesOptions.Subdirs); ? God when ppl ask for adding some features from other languages to Delphi I guess they don't mean this Javism 🙂

Use some judgement. You don't need to get rid of all booleans. Code like: SetControlsEnabled(True); SetMenusEnabled(True); SetFeaturesEnabled(True); is perfectly fine. Does it make sense when you read it? Yes, of course it does. What you need to watch out for is code like: EnumerateFrogs(True); Nobody reading that can infer what the argument does.

or use a const 🙂 const FILESEARCH_RECURSIVE = True; FILESEARCH_NONE_RECURSIVE = False; ... ... TFileSearcher.FindFiles('c:\', FILESEARCH_RECURSIVE); ... ... [edit] already mentioned i see now, sorry For myself i prefer the enumating way by the way.

What is thread safety anyway?

Whats the purpose of copying bitmap to a (linear) stream ? This sounds as its for saving to disk.

A truly shockingly bad one at that!

I did quick & dumb test that has shown that 100 ScanLines on 5000*5000 bitmap takes 5 seconds (!) because bitmap is recreated in every call. So this is the real handbrake. Looking at TBitmap.GetScanLine you can extract necessary parts provided you have the pointer to the 1st row from initial ScanLine call. BytesPerScanline helper method is public so this even won't be a hack.

For your reference, his original article was In Which I Argue That Embarcadero Should Open Source Their Unit Tests By Nick at July 27, 2013 04:27 which is no longer online, but archived at http://web.archive.org/web/20200109055953/https://www.nickhodges.com/post/In-Which-I-Argue-That-Embarcadero-Should-Open-Source-Their-Unit-Tests.aspx

I use FindFiles('c:\', RECURSIVE_YES); with a bunch of predefined boolean constants.

It makes missing string quotes obvious, and it helps clarify text building expressions.

Hello, I don't know if someone still follows this post, but I want to share my experience with Delphi push notifications: Using 10.4 to create an Android app, when running the following code : uses System.PushNotification; PushService := TPushServiceManager.Instance.GetServiceByName(TPushService.TServiceNames.FCM); PushService was always nil. I tried everything I found on the internet, but nothing worked. The magical solution: use FMX.PushNotification.Android, System.PushNotification; I hope this will save some time for someone.

I can't see how resampling would make it any faster unless your streaming implementation really sucks. Resampling would mean that you'd have to read all the pixel data, juggle it around, store it in a new buffer and then read from that buffer instead. Considerably more expensive than whatever solution you can come up with that just reads the data via Scanline. You haven't shown how you RGBA and RGB types are declared but assuming the R-G-B ordering are the same and the A is the last (i.e. high) byte then just read 4 bytes (that's a DWORD) from the source and write 3 bytes. Rinse, repeat. If the source is ABGR and the destination is RGB (e.g. TColor) then you can rearrange the bits like this: function ABGR2RGB(ABGR: DWORD): TColor; begin Result := ((ABGR and $00FF0000) shr 16) or (ABGR and $0000FF00) or ((ABGR and $000000FF) shl 16); end; or in assembler: function ABGR2RGB(ABGR: DWORD): TColor; asm mov EAX, ECX // Remove this for 32-bit rol EAX, 8 xor AL, AL bswap EAX end;

Hmm I guess some of us has had too little sleep at night because I don't get your point. Of course properly named parameters of enum type carry more info than plain boolean. But they involve too much overhead and pollute namespace so I prefer a little bit of mystery the booleans bring

I don't know if there is some other reason, but one reason is that with interlocked reference count you can freely use reference counted instances of any type (interfaces, dynamic arrays...) in multithreaded environment for read access if all threads have acquired their strong reference before original reference has been written to (cleared or assigned). In such case you don't need any other more costly locking protection, and you can share same string, so no copying necessary. Clearing such references when they go out of scope is thread safe, because memory deallocation will happen only in case where reference count reached 0. Also getting strong reference from strong reference (variable) held by thread is also thread safe - when I said held by thread it means that no other thread is allowed to write to that variable.

Yes. But my point is: even with this critical section protection and even with this read-only use case - ref-counts still should be interlocked.

Maybe using pointers to avoid index computation?

I also highly recommend the book "Code Complete 2nd Edition by Steve McConnell"

Two books that are gold for picking up good coding habits - even this long after they were written: Code Complete 2nd Edition by Steve McConnell Framework Design Guidelines by Krzysztof Cwalina & Brad Abrams (Third Edition)

Two things: 1. I really try my best to avoid negations in booleans 2. I try to name methods that do stuff like verbs and where possible put the parameter in context of the name Hence processOrder(aUseWidget: Boolean) { if aUseWidget then { processOrderWithWidget(); } else { processOrderWithoutWidget(); } } And SetControlsEnabled; // Implicit True SetControlsEnabled(True); // Explicit SetControlsEnabled(False);

Nothing to see here. Carry on using const for string parameters. The issue is vanishingly rare. If you encounter the issue, fix it. Don't go changing existing code unless you are actually affected by the issue.

No, it is not.