Leaderboard

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.

Heated discussions that end well - No problem, IMO. Discussing in writing is always difficult. Differences such as cultural background and language can make it easy to trip up and come across the wrong way. As long as we are patient and try to stay positive and on the ball instead of the man - there is hope.

Well ... so the conclusion is: If you have a project with 1 million (!) typed constants, then the 64bit-compiler is significant slower. Okay. This might be the case. But what now? Feel free to create a bug-report (for me it would be more a feature-request) at Embarcadero.com - I still struggle to find the direction and the goal this discussion still has.

@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)!

https://quality.embarcadero.com/browse/RSP-28886 try to run: sudo apt-get install curl

Today I discovered a new FastCGI implementation for the Ngix web server in Delphi and think I'd share it with you: https://github.com/kylixfans/FastCGI PS, I didn't make this - it's by my fellow countryman, but I guess here is the best sub-forum to make such a post?

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

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 ? I think that I really don't care about the underlying implementation detail. I just want truly constant typed constants. It would allow me to write consistent, readable, reusable code and allow array parameters and typed constant parameters for attributes. A minor performance penalty would be acceptable if that goal could be achieved.

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

Cut'n paste and RX replace. That said: It is unlikely that I'd have more than a few thousand typed record constants. I.e. The increase in compiler time is for all practical purposes insignificant.

You got the source. Be my guest.

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.

My most common use of typed constants is records containing translation strings. These are used for in-place translation of errors and prompts in JsonRPC responses, instead of the typical translated resource solution you would use in a desktop application. This is done to reduce the cost of lookup, since the same server will be required to respond to requests in multiple languages. It works so well that we've started using the same system for configuring text for grids, etc. - just to simplify the process of adding new content without requiring more translation work in a separate tool. For me, the benefits are that the translations are kept in one place - so it is next to impossible to mistranslate a text, or forget about adding a translation in a specific place when adding a new language and since the texts are in the source code, it is trivial to add new translations. I have hundreds of these typed constants and if they do add compile time, it must be next to nothing, because I can't say that I notice any slowdown in the compilation. My main gripe is that I cannot pass these as parameters to an attribute. Here is a simplified albeit rather contrived example but it illustrates my point. program TypedConsts; {$APPTYPE CONSOLE} {$R *.res} uses System.Classes, System.SysUtils, Vcl.Graphics, Generics.Collections; type TxStyle = record font: string; size: integer; attr: TFontStyles; end; type TextStyle = record const // typed consts within a record to create a pseudo namespace Title: TxStyle = ( font: 'Arial'; size: 12; attr: [fsBold]); Chapter: TxStyle = ( font: 'Arial'; size: 10; attr: [fsBold]); Section: TxStyle = ( font: 'Georgia'; size: 10; attr: [fsBold]); Normal: TxStyle = ( font: 'Arial'; size: 9; attr: [fsBold]); Code: TxStyle = ( font: 'Courier New'; size: 9; attr: []); Hint: TxStyle = ( font: 'Garamond'; size: 8; attr: [fsItalic]); OhNoes: TxStyle = ( font: 'Comic Sans MS'; size: 8; attr: [fsItalic]); end; type FontAttribute = class(TCustomAttribute) Style: TxStyle; constructor Create(const aStyle: TxStyle); overload; constructor Create(const aFont: string; const aSize: Integer; aAttr: TFontStyles); overload; end; type TText = class private FText: String; FStyle: TxStyle; published property Text: String read FText write FText; property Style: TxStyle read FStyle write FStyle; end; TParagraphs = TObjectList<TText>; //{$define UseRec} // Define to use the record format, undefine to use the individual fields // Regardless of defined or not, this does not compile. TDoc = class // would have a method to crawl the type RTTI and initialize the style attributes. private FTitle: TText; FBody: TParagraphs; public {$ifdef UseRec} [Font(TextStyle.Title)] {$else} [Font(TextStyle.Title.font, TextStyle.Title.Size, TextStyle.Title.attr)] {$endif} property Title: TText read FTitle write FTitle; {$ifdef UseRec} [Font(TextStyle.Normal)] {$else} [Font(TextStyle.Normal.font, TextStyle.Normal.Size, TextStyle.Normal.attr)] {$endif} property Body: TParagraphs read FBody write FBody; end; { FontAttribute } constructor FontAttribute.Create(const aStyle: TxStyle); begin Style := aStyle; end; constructor FontAttribute.Create(const aFont: string; const aSize: Integer; aAttr: TFontStyles); begin Style.font := aFont; Style.size := aSize; Style.attr := aAttr; end; begin try { TODO -oUser -cConsole Main : Insert code here } except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; end.

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.

Eh, quite disappointing actually. They turned such a good topic into: https://xkcd.com/386/

That is some really bad advice. https://devblogs.microsoft.com/oldnewthing/20070219-00/?p=27963 (read all 4 articles in the series)

Show me some evidence based on measurements.

I'm not sure if I understand your UI architecture fully, but here's what I would do: Use actions - always. One actionlist per form/frame. Replace forms with frames if possible. If you're embedding the forms then you should use frames. The form events are convenient but they are meant for more or less autonomous forms. Forms can be embedded but they are not designed to be so. Unlike frames. Move the activation/deactivation logic from the form to the container. Have the container notify the frame when it's activated and deactivated. Disable the frame actionlist when the frame is deactivated. Enable it when it's activated. Might not be necessary though as the actionlist is smart about not handling actions for controls that aren't visible.

Indeed Delphi x64 compiler has a poor implementation, but that's not the primary reason why it performs slowly than an x86 compiler ! In fact, If you've ever used a toolset other than Delphi, you wan't give such explanation ! you'll just realize that compilerX32/linkerX32 outperforms compilerX64/linkerX64. E.g : MSVC (are MS and other teams implementing a super implementation for x86 and a poor one for x64 too ?????). The reason behind this is subject to the following(but not limited) : - x64-Linker uses long type for calculating addresses. (Int64 vs Int32). - x64-Object file size usually is greater than a comparable x86-object file. - x64-Linker does an extra heavy work : fixing/linking exception tables (SEH). - Finally, It's not fair to compare x64 vs x86 (different file-format, different arch, different exception mechanism, ...). - ... FYI, this is slowly going to change (a lot of efforts are made by clang/gcc/icc) but still an x64 toolset has a lot of challenges. First, even if the test is unrealistic, I want to point you that I did my best to make a very fair test comparison : - I compiled tests without debug-info ( flavor for typed-constants (TC)). - Each symbol is used ONLY once ... meaning only one relocation (favor for TC). - All symbols are declared on the same file (favor for TC). - No detailed map file (favor for TC). - I used short name for all symbols (favor for TC). As you can see, all the above conditions where made in favor of TC (I wanted a true fair conditions !). In a real world, breaking the above rules is very easy and may lead to slow compilation. Second, I will give you a real world example where a usage of just 32 typed-constant can slow-down compilation : unit BinarySearch; interface const BIT_0: Integer = 1 shl 0; // .. const BIT_31: Integer = 1 shl 31; function binary_search(value: Integer): Integer; implementation // node count > 10K function binary_search(value: Integer): Integer; begin if( (value and BIT_0) <> 0)then begin // state0 if ((value and BIT_X) <> 0) then begin // state1 // another if ... // terminal node. end end else begin // statex if ((value and BIT_X) <> 0) then begin // another if ... // terminal node. end end; end; end. Here is a sample tree, tree2. The first time I developed the code for pascal, it was looking just like above (the decision behind this was to increase readability/debug). When everything was working perfectly, I decided to replace BIT_X with hex value (I wasn't comfortable seeing unppaded text) ... When I did this I noticed a small improvement on compilation time ... the reason that made me investigate on typed-constant ! It was a small improvement but noticeable ! Now, if you still insist, than you should really start giving me a good explanation -as I did- (forget about good explanation, just give an explanation or even come up with just a theory) why a typed-constant does not add any extra overhead on the compiler/linker ?

Since I gave an explanation, I believe that it's you who should give a test! Anyway, I made a simple Perl-script that generates random constants values and a dummy function that consumes those constants: unit DummyTypedUnit; interface const A0 : Integer = RandomValue; ... AN : Integer = RandomValue; implementation end. // ----------------------------- unit DummyUnTypedUnit; interface const A0 = RandomValue; ... AN = RandomValue; implementation end. program [Un]TypedTest; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils, Dummy[Un]TypedUnit in 'Dummy[Un]TypedUnit.pas'; function Dummy(Input: Integer): Integer; begin Result := 0; if Input = A0 then inc (Result); // ... if Input = AN then inc (Result); end; var i: Integer; begin Read(i); i := Dummy(i); WriteLn(IntToStr(i)); end. For each n time, I compiled both test on x86 and x64: # result ; second time # n = number of constant # time in min.sec.ms # x86: # ---- n = 100 : untyped : 00.01.12 typed : 00.01.18 n = 1000 : untyped : 00.01.14 typed : 00.01.16 n = 10000 : untyped : 00.00.88 typed : 00.00.82 n = 100000 : untyped : 00.05.85 typed : 00.06.26 #x64: #---- n = 100 : untyped : 00.01.10 typed : 00.01.09 n = 1000 : untyped : 00.01.12 typed : 00.01.15 n = 10000 : untyped : 00.01.56 typed : 00.02.02 n = 100000 : untyped : 00.08.90 ; 00.06.48 typed : 01.00.95 ; 00.48.15 I did my best to make them run on a fair conditions : - Declaring constants in the same unit. - Using a short name for constants. In a world where typed-constants are declared on different units and mixed with long name/type things may get worse specially for x64 ! Let me know if you need to test yourself, I'll be glade to send script and tests.