balabuev

Did you know that the following will automatically work with TDictionary: type TMyKey = record public class operator Equal(const A, B: TMyKey): Boolean; function GetHashCode: Integer; end; Without the need to write custom equality comparer. At least in Delphi 12 it works. And System.TypeIfo unit contains GetRecCompareAddrs function, which is used in default equality comparer implementation. I realized it only recently, and see no docs/info on the internet.

Immediate code-completion is good. Dreamed for it for a long time. Additional code-completion settings - also cool.

Self is used for demo code clarity, of course it is not needed here. Yes, you right the code is shorter with inline variables (i don't have them in mind because I usually write libraries for XE2+, so my fail here). Yes, the side effect of bracesless functions calls. Still it looks like inconsistency. By the way, as I mentioned, even "@ProcX" does not help. Yes, you right. And the ClassTAncestor hack is needed because Seek is a virtual method, otherwise we can resolve overloads simpler: Base := TStream(nil).Seek;

I see the topic is old already, but anyway, I'm searching for something faster. So, here is my try: type TAncestor = class procedure ProcX; virtual; procedure DoSomething; end; TDescendantA = class(TAncestor) procedure ProcX; override; end; TDescendantB = class(TAncestor) end; procedure TAncestor.DoSomething; type TProcX = procedure of object; var md: TProcX; begin md := Self.ProcX; if TMethod(md).Code <> @TAncestor.ProcX then // Overridden. else // Not overridden. end; This is faster than previous solutions, but I don't like complicated long code (type declaration, md variable). Btw: procedure TAncestor.DoSomething; type TProcX = procedure of object; var md: TProcX; begin md := Self.ProcX; // Compiles. md := TProcX(Self.ProcX); // Invalid cast :)). // And so: if TMethod(Self.ProcX).Code = ... then // Also invalid cast. ; if TMethod(TProcX(Self.ProcX)).Code = ... then // Also invalid cast. ; // Using "@Self.ProcX" does not work too... end;

Well, if Embarcadero afraid every single conditional jump, I have nothing more to say. However, even this additional stuff, which has been noted several times, have not been explained. Seems to me invented on-the-fly...

No sense to report QP.

If we speak about priority, then I agree, goto is not a frequently used feature. And goto with try/finally - even more rare :). They created code generation for other platforms, like x64 and Android. They added anonimous methods and inline variables - features much more complex than the discussing "goto". So, I understand the answers, like "its not a high priority thing". But, I cannot understand the answers like "its impossible/hard to implement" or "ooo, it will require one additional conditional jump" :) Who cares really about one additional jump?.. I'm personally would prefer that they fix "undo" functionality in the code editor. Code editor, like compilers, is the heart of the IDE...

Actually, I occasionnaly found my old post with possible combinations of try/finally and try/except and gotos. Re-read it, and found that all cases are ok, except of one. After that I simply followed comments in the topic 🙂. It's strange to me that people here do not want to make the language more self-consistent, especially in this particular case, where not big amount of work in the compiler is required.

You right, but I think other platforms work similarly. Can check in Win64 and Android. But, what is more important is that it's absolutely identical to Break or Continue, and because of that it will not require, as you said, "significant work in the compiler". Yes, I wanted to mention that also.

Things, which happens inside finally handling block is not relevant to the discussion, because it happening independent of what exactly causes finally code to execute. It may be Break, it may be exception raising. If we speak about "involved" - yes, several jumps are involved. But, this is a nature of try/finally. They are equally emitted for any finally block, and involved even when finally is executed because of exception raising - the main reason for "finally" to exist. So, these jumps are not even related specifically to Break or Continue. However, we mostly discussing here enchancing of the compiler - the newly required functionality is matter, not existing currently. So, I claim that to support goto with finally(ies) the emitted code will not be in any way more complex than it is now for Break. Specifically, a single "call" instruction for every exiting finally, and a single unconditionnal jump instruction. To be honest, managed local variables in a destination scope complicates the thing, but this is a separate, independed of try/finally aspect.

It would require transferring control to the finally blocks just identically to Break and Continue - One "call" instruction for each exiting finally and one unconditional jump.

You are wrong. Can you provide sample code, in which a single Break will require more than one jump? I mean the code in which I can comment the Break and compare generated asm.

I cannot imagine, where the difference come from. Moreover, handling finally is a "call", not jump. So, what Break do, is a single "call" to handle each exiting try/finally, and then - usual jump. So, goto should do the same.

No doubt that eror placement is not good too, since the message itself is about specific goto statement, not about the label generally. But, it's not matter. What is matter - the error itself. They implemented actually the same under-the-hood functionality for Break/Continue, but ignored goto. Because, who need it, right?

Not a big deal. Actually, even worse for a compiler 🙂

Yes, my fail. Should be: try goto L1; // Compile error, but why? finally end; L1: Not more mess than Break, Continue or usual "goto".

While compler implements it for Exit, Break and Continue.

Same thing, Exit, Break and Continue do, of course, - execute finally(ies) and jump out.

This one is interesting: try goto L1; // Compile error, but why? finally end; L1: Exit, Break and Continue work in the above case.

Do I understand correctly that a control, which is not a TWinControl (for example, TLabel), has no way to implement flicker free drawing with VCL Styles turned on? It seems that the parent form erases its own background via TFormStyleHook.PaintBackground not excluding child controls. This happens in both: Form.DoubleBuffered = False and Form.DoubleBuffered = True modes.

Hmm. It's helped to some degree.

I copy-pasted LSP from 11.1 as has been suggested above (fortunately, I have 11.1 installed on VM).

I do not experience this issue. Not with D10.4, not with D11. So, from my point of view, both version work approximately the same in this aspect.

I cannot agree with that. Moreover, 10.4 has a way to disable LSP in favor of old code insight engine.

Ctrl+G is also quite limited. Not work for stuff from library files, not work for unit names in "uses" clause.