Anders Melander

Sure, I use them myself. But not for code and declarations.

Include files works just the same in Delphi as they did in TP. It's just that we don't use them as you describe anymore. Not because it isn't possible but because there are better ways of doing things now. Memory size? Do you think an application uses more memory because it uses units instead of include files? Well, it doesn't. And, if anything, using units will generally produce smaller exe files compared to include files. You really should read the documentation I linked to - and more. So far most of what you have written are caused by not understanding the basics of Delphi.

Yes, that's what you would use units for if you programmed in Delphi - but of course you can pretend that it's still 1985 and continue using include files, if you prefer that.

The functionality you describe is provided by units in Delphi. Please read: https://docwiki.embarcadero.com/RADStudio/Sydney/en/Programs_and_Units_(Delphi) While Delphi does support include files (.INC) you generally only use them for declaring symbols or constant values used as feature switches or, in rare cases, for cross platform support.

There isn't. You can do one of either: Add the path of the component source to the global library search path: Tools->Options->Language->Delphi->Library path Add the path of the component source to the project library search path: Project->Options->Building->Delphi compiler->Search path In general I would recommend #2 and, if possible, try to keep the path relative to the project.

TBitmap.AlphaFormat is broken beyond repair - literally. See: https://quality.embarcadero.com/browse/RSP-26621 If you need to handle 32-bit RGBA bitmaps, use something that was designed for it.

...depending on your definition of "soon" 🙂

FPC seems to have accepted (or rather resigned to) the Delphi syntax: https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/1037 ...which is a present surprise, given their usual attitude towards all things Delphi (see the inline vars discussions, for example).

Perhaps, but I seriously doubt that it's a representative metric with regard to the needs of the current Delphi users. In all of the Delphi shops that I've ever worked in, I think I was the only one who ever posted something there and even I gave up on that in the end.

Yeah, right 🤦‍♂️ More syntactic sugar, the compiler codegen is still a joke, and we still haven't got SIMD intrinsics. The only time I've ever wished for a ternary operator was when porting C code and being in a rush. But I wouldn't mind all this fluff (since I don't have to use it) - if they would also throw an occasional bone to those of us that need low level performance. Yes, but you don't have to use it.

Delphi 1 ; procedure TObject.Free ObjectFree: MOV BX,SP LES DI,SS:[BX+4] MOV AX,ES OR AX,DI JE @@1 MOV AL,1 PUSH AX PUSH ES PUSH DI LES DI,ES:[DI] CALL ES:[DI].vtDestroy @@1: RETF 4 Delphi 2 procedure TObject.Free; asm TEST EAX,EAX JE @@exit MOV ECX,[EAX] MOV DL,1 CALL dword ptr [ECX].vtDestroy @@exit: end;

Again: There is no type conversion. A hard type-cast is not a type conversion. It's just telling the compiler to treat a variable as a specific type even though it actually is another type. The compiler allows this because the types are of the same binary size.

Why? What in that assembler makes you think that? TInterlocked.Exchange(pointer, pointer) and TInterlocked.Exchange(TObject, TObject) are both implemented with a call to AtomicExchange. That's the: call $003819a8 There's no type conversion as such. The compiler just doesn't inline the call as it should.

Can you ask him what he did? I can't decipher it from the commit diff. The algorithm appears unchanged though.

My guess would be that you could just disable the TListView actions when the control isn't focused.

Fair point. FWIW, I doubt that the method it uses can be improved much; Small color bitmaps often employ techniques such as unconscious inference, color psychology, and patterns to trick the brain into producing a better image than what would normally be possible given the available pixels. Larger bitmaps is another story.

What's the use case for this? I mean what problem does it solve? Given that it just converts pixels to vector rectangles I don't really see the point. The blurriness you get when upscaling a bitmap is by design. You can just use another resampling method if the blur is a problem. (Just thinking out loud, so to speak; I understood that you aren't the author)

Exactly.

That's a really stupid chart; It's displaying percentage of "marketshare". But what is the market here? It's the OS market - regardless of platform. So your server gets a vote, your fridge, your phone, your car, your nuclear submarine targeting control system, they all get a vote. Windows and the VCL primarily targets the Server or Desktop segment so those are the only that are relevant. It's pretty irrelevant that the majority of smartphones are running Android and the majority of embedded systems are running Linux, because those platforms are not targeted by Windows or the VCL. I believe Linux surpassed Windows in the server segment many years ago, but we can't see that from the chart.

Profile it. The significance of the overhead really depends on what the routine is doing and how often it is called. For example if the call overhead is X but the routine itself takes 1000*X to execute then the overhead is insignificant. Apart from the overhead of the call itself there's the overhead of passing parameters. You need to learn how parameters are passed in order to optimize them. Not all parameter types can be passed in registers, Delphi doesn't use all available registers, 32-bit and 64-bit does things differently, etc. Also be aware that if you pass literal floating point numbers as parameters, the compiler might not consider the literal values to be the same type as the parameter which means that it will produce code to convert the values to the correct type. For example, if the parameter type is Single and you need to pass 0.5, then pass it as Single(0.5) - or declare a typed constant with the value and pass that. Set Code Inlining Control=Auto to have the compiler automatically inline small routines. With regard to writing stuff in assembler be aware that assembler routines can't be inlined so the call overhead becomes mandatory. For example, in my code one constant bottleneck is calls to Round and Trunc. I have assembler versions of these two functions which are much faster but unfortunately the call overhead completely eliminate the performance gain so they are basically useless. It's beyond me why Delphi doesn't implement these two as intrinsics. They are listed as such but they are implemented as regular functions. Not only that, but the Pascal version will provide a reference implementation to test and benchmark against and it will help documenting what the assembler versions does.

LdrRegisterDllNotification (Vista+) LdrInitShimEngineDynamic (undocumented, XP+ AFAIK)

They are probably too busy Getting Real Help For Free With Code Reviews, Pull Requests, And Git Commits. 🤡

No. You are wasting your time.

QuickJS is a javascript engine while pas2js is a transpiler that emits javascript. Not even remotely the same thing.

Needs more arrows!