Leaderboard

Perhaps they could buy Greenland as well

This is rather sad fact(s). Both that talking about bad coding practices is considered trolling as well as fact that after of decades of discussions and knowing that certain code is bad it is still widely used and all warnings are ignored. Embarcadero cannot possibly take in account every single line of code out there. Problem here is inherently in 'with' and not in adding additional functionality. Every change has potential to break some code somewhere, but with attitude that nothing should be changed we would have no progress. That does not mean that bad code changes will not happen. We are not discussing other languages here. 'with' is the problem within language itself. You can shoot yourself in the foot with 'with' even in single line of code. Again, main problem is that code may break due to far away changes you may not even be aware of. 'with' makes code fragile and prone to breakage more than it would be without it. Any code can be broken one way or another. Point is minimizing accidental and subtle breakage as much as possible. On this we agree. With every rule there are few exceptions. That does not mean we should not strive to educate about particular code dangers, especially when benefits are minimal or non existent and can be obtained by using different techniques.

Regardless of is WITH statement good or is it bad it's a part of language and debugging, refactoring and other code tools should be aware of it. As a bonus, it may also hint which identifiers come from which scope

Not so much humour as a comment about the arrogance of imagining that the big company can just decide to buy the small company. Perhaps the small company is happy to be independent.

This is a quote from Knuth's C adaptation of the original Adventure game by Will Crowther:

What the hell are you talking about? CLANG is the LLVM frontend for C++ - so basically what Embarcadero did for Delphi. The difference is that I don't know how many people are working on CLANG (including people from Apple, Microsoft, Google, ARM, Sony, Intel and AMD) instead of one and a half men for the Delphi one...

Guess what - there are even rules that will tell you when you access things without using this in static code analyzers - and there are good reasons to do so (although I personally dislike it) Speaking of programming language design - you never can make everything perfect and there are always features that have some "be careful with it!" tags on them. However features that are so often accused of causing problems or confusions can be declared bad. And yes, every language has them and every responsible Developer should know when it safe to use them. Fun fact: I just recently consciously used goto because it yielded a noticable performance gain and rewriting the code without it would have been a massive undertaking resulting in more complicated code than just putting a goto there. And no, no raptor attacked me (yet...)

Oh, yes. you can pass 1..n units. Of course, what you may get, with name collisions -- which will not be reported -- is up for grabs. (Note that FixInsight now checks for with clauses which use more than one unit.)

What is sure with "with" discussion is that it is a trolling subject in the Delphi community since decade(s). For instance, the topic is about "with" in general, and that @Yaron stated that the IDE debugger has troubles with it. TRect came as a true problem about "with" - I do agree with Stefan. But problem came from Embarcadero, not taking into account existing code base. Just like ARC, or the AnsiStrings... Most dev people outside this forum would argue, paraphrasing @Dalija Prasnikar, that 'Delphi is a relic of another time and another coding practices: for instance, there is no GC !'. Php adepts would argue that writing $this->foo is much cleaner/safer than what Delphi (and other languages) do about properties. I like "with" - when properly used for two-liners code - as I wrote. It is a clean way of writing code, "making it easier to read" as wrote Yaron. Similarly, I like "object" more than "record with methods", since it allows easy inheritance - when using high-performance code with pointers and pre-allocated memory buffers/arrays. Of course, with only static methods. This was just my 2 cents, to introduce another POV into the discussion. Nothing is totally black nor white.

This occurs not only with the Delphi/LLVM compiler. The Oxygen compiler show this too: https://talk.remobjects.com/t/updated-benchmarking-oxygene-island-versus-delphi-c-c-and-net/19499 A compile time comparison is also given under the link above: Other LLVM compiler show the same problems, but do have a better code generation.

No LLVM optimization is really disappointing. If you wind the clock back to 1995, many of the early developers coming from VB3 were exited about a compiled executable that ran at the same speed as "C" programs. They wanted and valued fast executables. Borland / Codegear / Embarcadero have each ignored this value their developers place on fast code and haven't improved the code optimization for 20 years. It seems they take a, "it's good enough" view. I'd encourage them to invest some time and include all the optimizations that LLVM offers (even if it slows down compilation speed for the Release Build). I think they'd be surprised at how well this would be received by the Delphi community. Steve

Only if you invent a cloning machine first.

with SomeUnitName do doesn't compile on my Delphi 10.3 (nor FPC). Compiler complains with [dcc64 Error] Test.dpr(200): E2029 '.' expected but 'DO' found

@Bill Meyer Is with UnitA, UnitB do even suppose to compile?

This difference will no longer exist when Windows also gets this LLVM compiler

When optimizations are turned off in Delphi IDE the code is worse: - Each assign to "sum" variable is a load to register from stack, modify register, store back to stack. Same for loop iteration variable "i". - Loop start is not on aligned address - Loop count upwards instead of downwards requiring a compare at the end instead of just jump if not zero. So the compiler do some optimizations but they are very very basic.

I agree. It seems no LLVM optimizations passes are enabled, which corresponds with what others have reported about the mobile LLVM compilers. And this is very disappointing.

Looks pretty much like -O0 assembly

Compiling this simple program: program test; {$OPTIMIZATION ON} {$STACKFRAMES OFF} procedure loop; var i,sum : integer; begin sum := 0; for i := 0 to 1000 do sum := sum + 1; end; begin loop; end. Generates the following code (Delphi Mac 64-bit compiler, release build): __project1_loop PROC push rbp mov rbp, rsp mov dword ptr [rbp-8H], 0 mov dword ptr [rbp-0CH], 1001 ALIGN 16 ?_001: inc dword ptr [rbp-8H] dec dword ptr [rbp-0CH] jnz ?_001 pop rbp ret __project1_loop ENDP Some point to notice: - The loop procedure has a stack frame even though we've turned them off - It does not try to use registers for local variables. Both "i" and "sum" are allocated on the stack. - Since the loop body has no side effects and the result is not used then the whole loop can be optimized away. This happens with the same code written in C and compiled with Clang compiler. Clang is interesting comparison because it also uses LLVM infrastructure so it gives an idea of what kind of optimizations that are possible. - If we were to change the loop so the result variable is used (by printing the content of "sum" variable) then Clang will recognize that the loop can be evaluated at compile time and replace it with the equivalent code of printing that constant. Again, Delphi does not do this. See result of Clang here.

Judging from the performance of the mobile compilers over the years I would say: no

Yes but don't ask me why - I've been told that some of the optimizations slow down compile time even more than already happening on LLVM based compilers compared to the classic ones but fwiw I would not care for longer compile time on release config.

Didn't work out that way for the Linux compiler.

Hi David, I'm certainly not an expert in this field. Over the years I've seen various speed benchmarks that suggest Delphi's Windows compiler produces executables that are significantly slower than those produced by the top C++ compilers (e.g. Intel). In the chess world (where I am an expert) the rule of thumb is a Delphi version of a chess engine will run about 30% slower than the C++ equivalent code bases (Critter is the engine that was developed in two parallel code bases). Let's face it, there doesn't seem to have been any work done on optimizing the code created by the Delphi compiler in the last 20 years. I'm just hoping the new backend will be better. Thanks, Steve

Very likely that it has the same code quality as the Linux compiler: https://quality.embarcadero.com/browse/RSP-17724