David Heffernan

Conceptually a list class is the same as an array. For sure it has extra convenience functionality, but it is still a random access array. So my philosophy is that consistency is achieved by having lists match arrays.

I'd have the range checks conditional on RANGECHECKS. Indeed that is how I do it in my personal collection library. 

You have to enumerate all the files and copy them. Put these files into a double null terminated list. 

COM should not be initialised here. It needs to be initialised by the owner of the thread. 

1 hour ago, dummzeuch said:

Mine is longer than yours:

 

XDOM_3_1: 27134 lines

 

That's one of the files I use to test the GExperts code formatter with.

One advantage of having only one huge unit is that everything is in one place. You simply add that unit to your project and that's it. No need to add any entries to the search path etc. But that's not my preferred coding style.

 

But I am sure that somebody somewhere has already hit the maximum file size of the IDE or the compiler (if there is one apart from the obvious 4 GB limit of a 32 bit program, I don't know). I have definitely read of somebody who has hit the maximum number of lines in a method.

I have a unit with 53kloc (hangs head in shame)

This is a branch or a fork in your SCM system. If you aren't using SCM then that's your problem right there. Solve that problem first.

32 minutes ago, Marat1961 said:

All programmers, for example, in C ++, are forced to use the same approach.

Don't think so

https://en.cppreference.com/w/cpp/language/enum

19 minutes ago, Kryvich said:

I would use different prefixes if possible.

That's what scoped enums are meant for

39 minutes ago, Mike Torrettinni said:

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 🙂

 

This is exactly the issue that scoped enums solves already.

7 minutes ago, Mike Torrettinni said:

What version are you using?

That's XE7.  It seems to me to be folly to design your code based on an IDE tooling issue, and especially one which is soon to be resolved.

Further, the issue at stake here, as always when coding, is far less about the experience when writing code, as the experience when reading code. It's not worth it to reduce the readability of your code to give a minor easing to your experience when entering the code.

Following on from my comment about complexity, I'm wondering what's wrong with this:

You don't need to remember anything. Why are you seeking complexity here? You seem to be trying to solve a problem that simply does not exist.

2 hours ago, Mike Torrettinni said:

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

Why is that harder than remembering something else, as you seem to want to do?

Why is complexity so compelling? 

16 minutes ago, Mike Torrettinni said:

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.

You'd be far better off using scoped enumeration. It forces you to fully qualify the enumeration. Instead of deciding what the solution is beforehand, you are better off understanding the options offered by the language and working with the language, not swimming against the tide. 

It all went downhill when Borland decided that function return values were actually var parameters. Which means that in the case of managed types they get initialized by the caller. 

A function return value really should have pass by value callee to caller semantics. 

What problem are you trying to solve? 

What's wrong with

vHTMLReportType := htTemplate;

45 minutes ago, Kas Ob. said:

Work on your algorithms, the higher level approach's, that what really bring you performance, TStopWatch will work as long you always use it and don't concern your self much with 50% increase in small loops, as no matter what you do, because the compiler is not on your side, while better algorithm might gain you many folds speed, instead of just double the speed per very small loop, a loop that takes 1ms ( usually loops with thousands entries might be measured in microseconds so not even a millisecond), while a repaint of the main form might take 1-10ms .

You missed step 1. Step 1: identify the bottleneck. It's a common mistake. 

All this incredible noise, and all Mike needs is to simply time his own program...... It's really so simple.....

40 minutes ago, Mike Torrettinni said:

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?

I don't really buy what Kas is saying above. Just time your actual program is usage scenarios that you care about.

After all, why would care about the performance of code that you never run? You only care about the code that you do run, or your users run. 

1 hour ago, A.M. Hoornweg said:

 

No!  But your reply made me double-check.

 

I  ran the original test in a "tbutton.onclick" event instead of FormCreate, expecting that it would make no difference. It's just my way of doing things.

 

Weird enough, it DOES make a difference. Inside FormCreate() the numbers are 495 and 241 ms. 

Why the heck does stuff run slower in an OnClick() event?

 

 

Because timing a for loop doing 1,000,000,000 iterations of nothing meaningful is nothing more than a low grade PRNG.

Put something realistic inside the loop, and then time it.

1 hour ago, Mike Torrettinni said:

Now that we know INLINE is getting improvements decades later

It isn't.

1 hour ago, Mike Torrettinni said:

I see no reason to doubt any other features have great future, too!

Hmm .....

57 minutes ago, Mike Torrettinni said:

the focus of this topic is why simple inlined function is not generating same code as non-inlined code

Well, it's reasonable to wonder about that, and Stefan talked about that.

But you actually spent a lot of time talking not about the codegen, but about performance. And the key point is that there is no performance difference for the two versions of the code that you presented, once you put the code in a context where it actually does something. After all, the code you showed doesn't initialise any variables, and just performs the exact same two comparisons on each iteration of the loop.

Here's a question for you, why don't you compare the run time of your code, with code where your for loop is removed? I bet it will be faster with the for loop removed. And the code does the same thing with or without the for loop. Obviously that's silly because the for loop is meant to represent some real world code. But it's only meaningful in the context of actual production code.

I've said it many times, but when you put your two variants into your real world program, you won't be able to tell them apart from the perspective of performance.

Can I ask again why you are timing something that has no relevance to the performance of the code that you care about?

Once you time these variants in a real program, you will find that you won't be able to detect any difference in runtime.  And then you will draw the conclusion that the best way to write the code is in a manner which avoids duplication of code, and which makes it easy to maintain.  You'll likely also decide that there is no real gain in explicit inlining of the function here, and will stop doing that.

10 hours ago, Attila Kovacs said:

looks like "TsgList<T> = record" should be "TsgList<T: record> = record"

Records can be managed types

38 minutes ago, Mike Torrettinni said:

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.

That's not the conclusion of this topic.

13 minutes ago, Mike Torrettinni said:

Yes, I admit I have a tendency to try optimize sometimes without measuring first.

Why are you doing this? Have you timed your actual program yet? Do the two options perform measurably differently? Is that code even a bottleneck?

This test seems pointless because the two strings are always empty. You never read the strings from a collection. You never compare two strings. 

When you put this code into a realistic setting you'll likely find that it makes no difference to performance which versions you use. 

The smells of premature optimisation. And that results in hard to maintain code. 

1 hour ago, Marat1961 said:

The conversation is about the Spring4D project.
For simplicity of heart, I ran the test in the IDE.
program Spring.Tests;

Show the code that raises exceptions that you think are a sign of poor design. Details matter.