David Heffernan

Surely all full time delphi programmers would be ecstatic with this.

This is what you mean by friendliness, respect, tact is it? Perhaps I'm missing the point.

Interesting contribution. Thanks.

He means that the difference in performance is so small as to be unimportant to him

I didn't mean to show you any disrespect. I'm sorry that it came across that way. All I meant was that I thought the argument that compilation speed was important was bogus. I really did not mean to upset you. I try hard never to make anything I write personal. To me it's always about the technical details.

I don't think that anybody here has used a straw man. And only two people have made any statements directed at an individual, rather than concentrating on the arguments.

Compilation time is not a valid reason to make that choice. I stand by that. Your own measurements backed up my point of view. It wasn't. I understand that, but there's no good reason why they shouldn't have the same relative characteristics. So whilst the x64 compiler may well be slower than x86, the x64 compiler should not blow up when presented with huge numbers of typed constants, in a way that the x86 compiler does not. A more plausible explanation to me is simply the history of writeable typed constants. At this point we all know what each other thinks, and there's little point repeating ourselves any more.

The biggest issue with constants in Delphi are that typed constants can't be used in certain settings which require true constants to be used. The ones that come to mind are: 1. When declaring typed constants. 2. When declaring attributes. The inability to used typed constants in these settings is clear weakness in the language. There are probably more issues, but these are the ones that bite me. I'm tired of hearing justification for these limitations based on the current implementation. All this talk about single pass, interface vs implementation, writeable typed constants, etc. If the implementation limits you, change it.

A few milliseconds during a typical compilation is insignificant. That's my opinion. Others may have a different opinion. They are welcome to it.

Now you are talking about the generated code. Which is a different issue. Hitherto there has been a long, and in my view bogus, discussion about compilation speed. The OP said that compilation speed was a reason to prefer avoiding typed constants. The point that I made which seems to have generated such noise is merely that speed of compilation is no reason to prefer true constants over typed constants. EDIT: I didn't read closely enough. You are claiming that the compile time must be longer because more instructions are emitted? Wow, that's weird. Known to be false also. Consider optimisation. Often this results in fewer instructions emitted, post optimisation. But optimisation is an additional step that can increase compile time There are good reasons to prefer true constants over typed constants. Compilation speed isn't one of them. Efficiency of generated code is one. Frankly I'm ambivalent about what you both think. If you want to change the way you code to save a couple of milliseconds of each compilation, then do it. It doesn't bother me.

Only for a totally unrepresentative example, and only because of implementation defects in that compiler. Not because there is anything conceptual. Feel free to choose between true and typed constants because of a few milliseconds difference in compilation time. If that means something to you, great. Knock yourself out. For me I will stick to what results in readable and maintainable code, and code that runs most efficiently.

And your code showed that they don't.

My point is that the difference in compilation time is insignificant, and absolutely should not drive your choices of how to write the code. Certainly for the DLL that I ship, that's not the case. The time spent fixing up symbols isn't great because there aren't that many.

Colours aren't hex. Hex is just a different way to write an integer, using base 16. For instance $10=16.

That's clearly a deficiency in the x64 compiler implementation since the x86 compiler doesn't suffer the problem. The x86 compiler demonstrates that the difference in performance is not due to a fundamental conceptual hurdle, but a poor implementation. We know that the x64 compiler performs very poorly. In any case the test is totally unrealistic. You aren't going to encounter this in real world code.

Show me some evidence based on measurements.

As I said, when I need to take the address. An example from my code base is when calling external code, written in Fortran, that expects values to be passed by reference always. You do. If you can't provide a real world example where compilation time is significantly impacted, then I call BS. I'm talking about the language as it stands today. Your original post was too.

The fact that you've never come across a need for taking the address of a constant doesn't mean the need doesn't exist. How about asking why this need arises rather than thinking you've seen all possible use cases for typed constants.

I didn't see the part where you measured compile times. It is true. We're talking about Delphi. We're not talking about some potential other language.

Conclusions seem bogus to me. I don't think the compilation speed is a factor, and there are plenty of times when you use typed constants for integers. The rules really should be: 1. Use true constants if possible. 2. Otherwise use a typed constant. The factors that force you to use typed constants are broadly because the type is a complex type which doesn't permit true constants. Or you need to take the address of the constant.

Wait a minute. If its a 64 bit add in then why are you casting the pointer to a 32 bit integer?

I highly doubt that wordID or hdl are really THandle. The latter should be HWND. Not sure what the former should be. THandle represents a kernel handle. It's something that you would call CloseHandle on. As for your problem, hard to know. Could be UIPI. You don't do any error checking when you call SendMessage. You need to add some trace debugging.

Couldn't take the traffic of tens of devs trying to vote for range checking enabled by default

Let's start by establishing whether or not there is a problem that cannot be worked around. Which integer value are you unable to declare as a literal?

I have a question for you. Which integer value are you unable to declare as a literal?