Mike Torrettinni

Interesting. Are you really using this construct instead of enums, in your real code?

I do, except when they are in different units or out of view in longer unit, i can make mistake. Of course it makes sense this is not really applicable for projects where only a few enums are defined and you can remember most of them. But i have a lot of them, so the need to organize them could differ in such cases. Not all projects are the same.

Thanks, this was already suggested. The organized Enums class solution seems very useful:

Most common mistake I make is when enums start with same prefix, like: TCellType = (ctNA, ct...) TCommandType = (ctNA, ct..) If they are within visible area of each other in the unit, you can choose different wording, but very easy to forget that ct is already 'used', if they are defined some time apart. I hope 10.5 will have much much improved LSP. But I must say I kind of like the idea of grouping enums together by content/purpose, within Enums class. Cool solution 🙂

OK, thanks for advice.

Aha, now I see understand what you are referring to. Well, in my experience, Code completion and Error insight are not most reliable features in Delphi IDE. They might (or not) work in simple unit examples, while a lot of times they break in larger units, or sometimes just a specific definition can break them. The new LSP is supposed to fix (avoid) these issue, but as far as reports go, it is improvement, but still not working 100% of the times. There are issue reports in quality portal on this topic. So, invoking code completion from empty space (like in your example) could/or not work. While code completion from Enums. behaves better, in my experience, works more often. I use Delphi 10.2.3, so code completion could differ between mine and your version. What version are you using?

This is working pretty good! Good thing is that this is only enum organization layer, all enums are still outside of class, so still can be used separate. I set a few more enums into Enums class and I can organize enums from multiple units, too.

Not sure how would scoped enums help me remember the names to use the correct one... I would still need to remember THTMLType, right?

Yes! 🙂

Nothing is wrong, both cases still work: Procedure(Enums.HTML.htTemplate); or Procedure(htTemplate); In second case I know the exact enum, in first case I can use code completion to help me.

Thanks for detailed explanation. A lot to think about. 🙂

...which is how it's normally done. You do this in every case? I only do this when enums are from multiple used units. like BorderStyle := Forms.bsNone; otherwise I never prefix enum with unit name.

This is awesome! It can be defined outside of class, too: type THTMLType = (htTemplate, htStatic, htHeader, htCustom); TGEnums = class type HTML = THTMLType; end; procedure DoIt(aHtml: TGEnums.HTML); begin end; procedure TForm2.FormCreate(Sender: TObject); var x: TGEnums.HTML; begin x := TGEnums.HTML.htTemplate; DoIt(x); DoIt(TGEnums.HTML.htTemplate); end;

No, I'm not sure scoped enums is what I need. I would like to have something that could use code completion, so I don't need to remember htTemplate. I would type Enums. and I would select among options HTML. and then I would see THTMLType options... (I added this into first post) I hope it makes sense.

Using Delphi 10.2.3 version: I have a very simple example of inlined function, that is faster compared to non-inlined function, but not as fast as no function call is executed: Goal with inlined function: the loop condition is used in numerous places, so I want to shorten the code and have 1 call to inlined function that replaces all these (same) conditions. I was hoping I can shorten the code to use function, and was assuming than inline will just 'replace' call to function with exact same condition as in function. So, in theory the execution should be the same. But loop without inlined function is 50% faster than with inlined function, approx: 1570ms vs 2175ms. uses System.Diagnostics; function IsSearchByValueFound_Inlined(const aSearchValue, aItemValue: string): boolean; inline; begin Result := (aSearchValue = '') and (aItemValue <> '') or (aItemValue = aSearchValue ); end; procedure TForm2.FormCreate(Sender: TObject); const loop: integer = 1000000000; var vSearchValue, vItemValue: string; i: integer; sw: TStopWatch; begin memo1.Clear; sw := TStopWatch.StartNew; for i := 1 to loop do if (vSearchValue = '') and (vItemValue <> '') or (vItemValue = vSearchValue ) then ; sw.Stop; memo1.Lines.Add(sw.ElapsedMilliseconds.ToString); sw := TStopWatch.StartNew; for i := 1 to loop do if IsSearchByValueFound_Inlined(vSearchValue, vItemValue) then ; sw.Stop; memo1.Lines.Add(sw.ElapsedMilliseconds.ToString); end; Is that just how it is, or am I missing something and loop using inlined function should run exactly the same time as loop without function call?

Thanks, that's the only level I can even try to optimize 🙂 I've only started looking at generated asm code recently (see thread about const records access with TList access) and it was interesting to see the pitfalls of the inline directive. I will try to look at generated code more frequent, so step by step. But prepping registers is way out of my league, for now. Usually I'm more interested in how I can improve performance expressed in percentages and not what this means in actual time - unless actual time is a big problem. So, if all my benchmarks use same 'not best optimized' library (TStopWatch), I'm happy if percentage of improvement is at accepted level, for the effort needed.

This is quite extensive prep work for accurate benchmarking. Do you know of any library that has something similar already implemented and is ready to be used?

You are kind of right, but that was a totally different kind of inline: Aha good to know. Now then this also make sense:

Google shows Turbo Pascal 3 already had INLINE directive. Wow, we are talking about a dinosaur here, and I thought it was recently added. Now that we know INLINE is getting improvements decades later, I see no reason to doubt any other features have great future, too! 🙂

Aha, OK. I was only able to see it is in documentation for Delphi 2010. As @Kryvich posted, it seems to have been improved in 10.3, unfortunately I still use 10.2.3 😞

Perhaps inline directive generates even less performant code in earlier Delphi versions. Not sure when it was released first.

DelphiCon schedule is totally unrelated to any release. It is just online Delphi conference. Previously we had CodeRage in about same timeframe. Based on past releases: https://delphi.fandom.com/wiki/Delphi_Release_Dates I'm not expecting 10.5 before fall 2021.

I'm still not sure what is missing from the original post. There is example and timing results, focused just on difference between non-inlined and inlined code. I also had timing for non-inlined function, which was the slowest, but the focus of this topic is why simple inlined function is not generating same code as non-inlined code.

I guess you are right, since I can't move to newer version, yet. Perhaps before or about the time of 10.5 release. Until then, I will have to accept that this example of inline directive in my code is not as efficient as will be in the future 🙂 Cache lines? New terminology to me, in Delphi. Perhaps at that time (moving to 10.4 or 10.5) I will also have more experience in benchmarking, because some details pointed out in this topic were completely new to me (like how registers, order of execution, TStopWatch init/reset, cache lines and other details can affect the results).

OK, makes sense. I would not expect some complex code to be inlined as if it's outside function, but just simple string comparisons I assume it could be working as expected. OK, thanks for this. I had no idea of such details. I believe now we confirmed that my version Delphi 10.2.3 is less efficient compared to 10.3 and up, regarding inline directive, so this topic is irrelevant when I move to newer version.