Mahdi Safsafi

@dummzeuch I used PChar instead of string in b_FindFirstExNextBFSClick and I got up to 20% improvement. I tested on Windows 10 with SDD on 'C:' drive.

I'm not very well experienced on FM, but possibly you're passing settings by value ! those could be a very hard source of bug to detect ! procedure TframeGauge.DrawArcAA(AParams: TAAArcSettings);

Thank you 😊 In the attached file, you'll find what I did and an interpretation to results (of course from my point of view). Let me know if you've any questions. program.dpr

I did a little experimentation to explore how compiler deals with rtti/qualified_name, let me know if you're interested.

You're absolutely right ... I just wish if your friend Daniel did too ! Now, we're clearly understanding each other. I got the feeling that you were trolling. You would clearly understand if role changed and you were at my place. I'm very sorry if this at any case hurts you.

Too bad @Daniel didn't saw that 😥

@Daniel You're not understanding whats happening here and yet you took David side ! Read carefully my answer, I didn't say at all David example/answer is wrong ! all what I said, David misunderstood my answer ... nothing more ! Rather than taking your friend side, It would be better to understand first what's going on ... ok ?

@David Heffernan First, do you really think that I'm missing a basic fact about RTTI ? FYI, my component TzObjectInspector is entirely build with RTTI ! Second, I really don't know what's the purpose of your example since I answered you "I know that, I was meaning RttiContext.GetTypes". I thought that would be enough to put you on the road. I'm still thinking that you're not understanding neither Attila question nor my answer. Third, I answered with the context of the question, from the first sight, I knew that Attila was meaning inquiring RTTI declared on a program (not a unit). Last thing, If that going to make you happy, I'll rearrange my sentence : Wasn't said explicitly ... but inquiring RTTI is available for public declaration. dpr project (program/library/console,...) are implementation (they don't have interface) those they are not public.

No, I think he means the use of TRttiContext.GetTypes function to get all types declared on a program file(console not a unit).

I believe he wants to illustrate all types declared on a program (not unit).

I know that, I was meaning RttiContext.GetTypes

Wasn't said explicitly ... but RTTI is available for public declaration. dpr project (program/library/console,...) are implementation (they don't have interface) those they are not public.

@Vincent Parrett It's not like they do not bother them-self to make a fix. The problem is that its a hard thing to do (at least if you want to stay native). The OS(Windows) is not helping at all ! I developed Vcl-styling for MainMenu/PopupMenu and system-dialogs theming with RRUZ(you may find a licence in Vcl.Themes unit). I can guarantee you that the big deal with styling Windows components is coming from the Windows side! MS for unknown reason does not want you to do that, and hides/un-document all the important parts ... forcing you to do painting in an ugly way which can cause flicker and all Vcl-styles related issues. A sometime ago, I was working internally on a native, better solution that implies using DDetours, For many components, it gave a much better result, a smooth, native drawing that has nearly zero cost overhead(I experienced no flicker, Scrollbars were true native -not as the current implementation-). Unfortunately, I got a very little time to work on that project and ended-up abandon/forgotten. Conclusion : If you want someone to blame ... blame MS.

Absolutely ! Few time, I saw people commenting (rather than just editing a post) in an explicitly provocative way just to embarrasses people. In fact, paying has nothing to do with that. Its defined by Hippocratic Oath. In a world(no-capitalism) where you don't have to pay for a medical service, your doctor still restricted by deontology ethics. You're right SO is a little bit different(different cultures all around the glob), but I believe that the platform could do much better toward that issue. Than I just hope that things get better there.

@David Heffernan Just one last thing that bother me with SO: There're a lot of people that use a high level vocabulary that any no-native English speaker would understand. Worse they follow grammar mistakes and embarrasses the man in a way (you missed 's', he/she/it ... come on !, ...). When you talk with your Doctor, the Doctor is confined by deontological ethics to give you a clean, simple and loyal information. I believe that should applies on SO too (A man asks question because he is confused otherwise he wouldn't ask). David and all SO influencers, your voice is heard ! Perhaps, you can start an initiation at least on the Delphi community (this definitely will make a difference).

David what you said is totally true. But I want to add something : For many times, I saw many people get humiliated for trivial reasons by people that just enjoy doing that and SO is not doing a good job there ! I'm not talking specifically to the Delphi area (I saw that behavior around all SO). Some of my friend refused to use SO just for a moral reason. Moreover, many developers don't agree with their policies.

If this going to make everybody relaxed than I definitely don't mind ! I really didn't want things to end like this. I started this topic because I found that Lars question was very interesting and deserves an explanation/discussion. At some point of the discussion, David used a word that made me angry and I just started stopping at the simple slip he makes (I'm not used to do such a thing ... Many of you guys know me from the old G+ community). Eventually, I ended-up showing high qualification than what the topic deserves(Which certainly gives the reader the idea that I'm swaggering). David gave apologies and this proves his high level of education. In my turn, I gave my apologies to @David Heffernan, sorry if I make you uncomfortable(you're a good man and a good developer too), and for everyone who read my topic and followed my discussion. @Lars Fosdal, @Daniel Feel free to make an action.

@Daniel Absolutely sure ! No one is insane to use 1 million constants ! A real world example would be using just 32-ordinal-typed-constants (instead of untyped-constants) to implement a binary search tree for a huge number of nodes. This will make a difference at : - Application size. - Performance. - Compilation/Linking time.

@Lars Fosdal I'm sorry, I misunderstood your example. You meant performance and I blindly assumed compilation-time.

Yes that happened to me too ! Splitting constants between two unit, solved the problem.

@Lars Fosdal You shipped a test for comparison ! You're asking for immutability ... this is hard to achieve on unmanaged system and specially for Delphi (breaking type-system compatibility). I think placing constants on ROM would be much better as it doesn't require changing the system-type language. What do you think ?

Don't worry ... it's not a big deal

@Lars Fosdal Thanks for your example ... nice addon ! but I believe there is a misunderstood here. There is a difference between ordinal-type-constant(Char, Byte, Int16, Integer, UInt64, ...) and structured-type-constant(record, array, string, PChar, ...). // these two are different definition : const A: Integer = 2; // Involves linker cooperation. const B = 2; // Does not invlove linker cooperation ... the compiler is able to handle it itself. // ----------------------------------------------------------------------------------------------------------- const Str : PChar = 'this is foo'; // Involves linker cooperation. const Str2 = 'this is foo'; // Involves linker cooperation too. But why it involves linker cooperation ? that's because structured-data must be allocated at the heap ! When compiling, the compiler have no information at witch address Str, Str2 would terminate to ! It will just emit an empty address and add some information about all empty case he left ... later when compiler finished, it gives the linker the necessary information and ask him to fix all the blank address. Now why the linker is able to know the address and compiler does not ? that's because the linker can see all modules (compiler compiles only one module at a time). I believe now you understand why your example isn't a real fair test for demonstrating typed-constants.

Adopting the historical reason is in somehow wrong ... because the Pascal-ISO didn't introduce typed-constants neither did the Extended-Pascal-ISO. FYI, I'm studying both ISO for a personnel usage. // A definition of constant in Pascal-ISO: constant-definition = identifier '=' constant . constant = [ sign ] ( unsigned-number | constant-identifier ) | character-string . constant-identifier = identifier . // A definition of constant in Extended-Pascal-ISO: constant-definition = identifier '=' constant-expression . constant-identifier = identifier . constant-name = [ imported-interface-identifier '.' ] constant-identifier . // Moreover : extended pascal allowed this : const BlankCard = PunchedCard[1..80: ' ']; blank = ' '; Origin = subpolar[r,theta:0.0]; column1 = BlankCard[1]; MaxMatrix = 39; pi = 4 * arctan(1); mister = 'Mr.'; As you can see the Extended-Pascal allowed a more relaxed form of constants ! So saying that the reason is related to historical reason can't be adopted. const MyData: array[ 0 .. 1000] of integer = (...); const element = MyData[1] + 1; // if the compiler allowed this ... it will come at a cost of compilation-speed (I already explained why). I didn't say it's a reason ! I said typed-ordinal-constants are volatile and not well optimized moreover they add extra overhead on compilation. They should not never be used. The example you give(Fortran) could be an exception. It would if x64 showed a close result to x64. I believe(I'm not sure) that's related to the OMF. A good way to find that is to check Delphi LLVM based compilers. If all compilers gave a close result to the dcc64 then it would enforce that ! Unfortunately I don't have any Delphi LLVM compiler on my machine. I'd appreciate from you or anyone else to do the check.

@Kas Ob. That made me angry ... He showed a disrespect for me. He didn't appreciate the detailed explanation I gave neither the time I waste nor the experience I have. First, I said that the reason behind why Delphi's compiler not allowing using complex-type constants (e.g: array, record) as true constants was compile time speed (and I clearly explained why ? as this involves processing the data for each unit that uses the const ) ... He refused to believe and said that the reason because the types are complex ! ... I gave him a day to day example from the D programming language just to prove that the complexity is not a factor ! And yet he answered : That's not a Delphi Style. Second, I said that any developer should avoid using typed-ordinal-type-constants(Byte, Integer, ...) as this will impact optimization and adds an extra overhead at the compilation-time... Yet he strongly believed that's not true ! ... Again, I gave him a good explanation (how linker work) ... He called my explanation BS and asked for tests ! I made a test and showed clearly that at least the x64 compiler was affected ... Yet he said that the test isn't a real-world test and blamed the poor implementation for x64 compiler ... And again I found my self clarifying his wrong beliefs (explaining why it's hard to an x64-toolchain to outperform an x86-toolchain). Indeed he is experienced in Delphi development, but still has a lot to learn -thinking out of the box- (using other toolchain, knowing how a linker work wan't hurt too, ...) ... this certainly will change his mind about many things and would make him open for argumenting (not because Delphi is doing it in an X way means that Y is wrong). This applies to everyone ... including me (learning is a good way to open your mind)!