Leaderboard

Fixed. You should be grateful that the CE is released at a point where it's the least broken version you can get.

Usually a mess we create ourselves 🙂 It may be that the dead thread raising the exception was trying to use an already disposed reference in it's final moments.

To be fair, if they didn't want it to be used, they could simply not make it available. So obviously, that is not what they are doing, right? What they are trying to do is straddle the fence between offering a free tool and taking in actual revenue to be a solvent company. Your posts don't seem very serious but if they are meant to be serious, it seems like you think that Delphi should be like VS. What you and everyone else who has made that argument fail to take into account is that Embarcadero can't do what Microsoft does, because Microsoft is pushing a much larger ecosystem, including enterprise cloud services that dwarf any cost that Embarcadero is charging for Delphi subscriptions. The two are simply not comparable. I do understand that most people today are freeloaders who think everything they want to use should be paid for by someone else, but Delphi is a product in and of itself to provide revenue for its owners, not a product to support a much larger ecosystem. They can't give it away for free, and whatever "free version" they do provide can't cannibalize their actual business revenue. So it will of necessity be limited.

VCL implements "garbage collection" for unused device contexts and it periodically releases them. To prevent that you need to call Lock on Canvas, and call Unlock when you no longer need the same device context. But, without seeing your code it is hard to say whether there is more going on.

True!!! Thanks for help!

Yes, this is it. It's a very important use case though. Imagine writing large YAML or JSON files containing a lot of data. And then imagine trying to do the same with multiple threads with extra contention on a memory manager. The point is that you build IntToStr using a function like mine above. And publish both. This allows the consumer of the library to have both options. Even if avoiding heap allocation is something that is only done in a narrow set of circumstances, that doesn't render it unnecessary.

I guess all the software that I've released in recent times didn't happen because I was using a useless tool.

From my codebase: // disable range checks and overflow checks so that Abs() functions in case Value = Low(Value) {$R-} {$Q-} function CopyIntegerToAnsiBuffer(const Value: Integer; var Buffer: array of AnsiChar): Integer; var i, j: Integer; val, remainder: Cardinal; negative: Boolean; tmp: array [0..15] of AnsiChar; begin negative := Value<0; val := Abs(Value); Result := 0; repeat DivMod(val, 10, val, remainder); tmp[Result] := AnsiChar(remainder + Ord('0')); Inc(Result); until val=0; if negative then begin tmp[Result] := '-'; Inc(Result); end; Assert(Result<=Length(Buffer)); i := 0; j := Result-1; while i<Result do begin Buffer[i] := tmp[j]; Inc(i); Dec(j); end; end; function CopyIntegerToWideBuffer(const Value: Integer; var Buffer: array of WideChar): Integer; var i, j: Integer; val, remainder: Cardinal; negative: Boolean; tmp: array [0..15] of WideChar; begin negative := Value<0; val := Abs(Value); Result := 0; repeat DivMod(val, 10, val, remainder); tmp[Result] := WideChar(remainder + Ord('0')); Inc(Result); until val=0; if negative then begin tmp[Result] := '-'; Inc(Result); end; Assert(Result<=Length(Buffer)); i := 0; j := Result-1; while i<Result do begin Buffer[i] := tmp[j]; Inc(i); Dec(j); end; end; function CopyInt64ToAnsiBuffer(const Value: Int64; var Buffer: array of AnsiChar): Integer; var i, j: Integer; val, remainder: UInt64; negative: Boolean; tmp: array [0..23] of AnsiChar; begin negative := Value<0; val := Abs(Value); Result := 0; repeat DivMod(val, 10, val, remainder); tmp[Result] := AnsiChar(remainder + Ord('0')); Inc(Result); until val=0; if negative then begin tmp[Result] := '-'; Inc(Result); end; Assert(Result<=Length(Buffer)); i := 0; j := Result-1; while i<Result do begin Buffer[i] := tmp[j]; Inc(i); Dec(j); end; end; function CopyInt64ToWideBuffer(const Value: Int64; var Buffer: array of WideChar): Integer; var i, j: Integer; val, remainder: UInt64; negative: Boolean; tmp: array [0..23] of WideChar; begin negative := Value<0; val := Abs(Value); Result := 0; repeat DivMod(val, 10, val, remainder); tmp[Result] := WideChar(remainder + Ord('0')); Inc(Result); until val=0; if negative then begin tmp[Result] := '-'; Inc(Result); end; Assert(Result<=Length(Buffer)); i := 0; j := Result-1; while i<Result do begin Buffer[i] := tmp[j]; Inc(i); Dec(j); end; end; {$IFDEF RANGECHECKSON}{$R+}{$ENDIF} {$IFDEF OVERFLOWCHECKSON}{$Q+}{$ENDIF} No heap allocation. I guess I could avoid that DivMod now and do something better. The main point is that a good runtime library should have building block functions like this that allow us to perform such conversions without forcing heap allocation. The RTL should have functionality like this on top of which all conversion functions can be built. Then the RTL function can be optimised and everyone benefits.

I don't know what to think after reading that article. Here are my comments on it: - the classic way of truncating the last 2 digits with div and mod 10 (or 100) does not involve a costly div or mod instruction on modern compilers (*cough* even Delphi 12 now does it - apart from the bugs that came with it) - I think C++ compilers would detect doing a div and a mod instruction and the code they emit would be further optimized so it does not require the "workaround" that the Delphi RTL uses by calculating the modulo by subtracting the div result times 100 from the original value. - the pseudo-code he shows for detecting the number of digits is correct but this is never what gets executed - and you either rewrite this into a few branches (as you can see in the RTL), a C++ compiler might unroll the loop or some other trickery is applied The DivBy100 function was introduced by me in RSP-36119 and I already notified them that DivBy100 can be removed in 12 because now it properly optimizes a div by 100 - however, that affects performance only by like 0.5% or so. As David correctly pointed out the real bottleneck is the heap allocation - and not only a single one when you just turn an integer into a string and display that one but when you concat strings and numbers the "classic" way because then it produces a ton of small temporary strings. That issue even exists when using TStringBuilder where one might think that this was built for optimization. If you look into some overloads of Append you will see that it naively calls into IntToStr and passes that down to the overload that takes string. This is completely insane as the conversion should be done directly in place into the internal buffer that TStringBuilder already uses instead of creating a temporary string, convert the integer into that one, pass that to Append to copy its content into the buffer. This will likely be my next contribution as part of my "Better RTL" series of JIRA entries.

I love the possibility to create and sell a monolithic exe, that can be dropped in a folder and just be executed, no installer necessary. That is of course not a distinguishing feature of Delphi, you could compile a C# application into a monolithic exe as well, but how often is that really done?

... of course I'm aware .... It was a ironical replay to @David Heffernan ... Mantra "But it compiles to native code!" is a must for my business, may be only for me but that's enough. I have customers with dozens of machines (industrial lines) who are tired of hearing about frameworks that must be constantly updated, incompatibilities between functional blocks (effectively DLLs and third-party components) with each update, technology changes for "opportunities" of suppliers (for example instead of working with .Net 4.0 there is now .Net CORE x.x) which make many solutions adopted on old machines incompatible with the new ones. We are not talking about Java applications linked to a specific JRE which due to their "incorrect" development cannot be selected from the application itself (so if there are multiple JREs installed... nothing works). The customer who does not have "programming" as his core business but only the use of an IT product is not interested in the outline at all... he is only interested in not having any kind of problem in using it for the next few years. This is. How much the machine code is optimized is not a problem for my applications, or at least what optimization there is is sufficient. If I want optimized and performant code I use C or C++ (as already indicated)...

This place isn't representative. Most developers don't participate in communities and don't even know they exist. I've worked at a lot of different places and with a lot of different developers in my career and I think I've only ever met one other developer IRL that participated in communities. Not that I can see. My experience with Lazarus/FPC is limited to using it to make some open-source projects FPC compatible but from my POW they are constantly playing catch up with Delphi. And I think Lazarus sucks as an IDE.

I don't care that much about the IDE. It's the compiler and the language that matters more to me.

But that's not what it is. It's Delphi 12. Like last time it was Delphi 11 and then 11.1 and then 11.2. So maybe the next one after 12 will be 12.1. Or maybe it will be 13. Or maybe 14. The fact that so many people have such problems with knowing the versions is a sign that their policy is poor. I'm expecting to hear about XE12 before long.

At least in 13 they would have an excuse for poor quality