<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-04-12 11:21 GMT+02:00 Sven Barth <span dir="ltr"><<a href="mailto:pascaldragon@googlemail.com" target="_blank">pascaldragon@googlemail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><p>> That might be, but this just adds a new category of possibilities for such bugs and that is something that we should not do, especially one as subtle as this.<br>
><br>
> One possible solution would be to disallow records with management operators for global variables (variables created for Default() might be an exception here, but I'd need to think that through).</p>
</span><p>Another possibility I just thought of: have the compiler analyse such inter unit dependencies in the initialization sections (yes, I know, easier said than done) and print a warning in case something might depend on the order of execution.<br>
If the user is at least aware that there might be something fishy going on then I'm more lenient.</p></blockquote><div><br></div><div>another way is to introduce attributes for selected language elements in Delphi compatible way. For example in Delphi we have:</div><div><br></div><div>  TCustomAttribute = class(TObject)</div><div>  end;</div><div>  WeakAttribute = class(TCustomAttribute);</div><div>  UnsafeAttribute = class(TCustomAttribute);</div><div>  RefAttribute = class(TCustomAttribute);</div><div>  VolatileAttribute = class(TCustomAttribute); </div><div><br></div><div>which is used like this:</div><div><br></div><div>procedure Foo([ref] const X: TFoo); // FPC equivalent is procedure Foo(constref X: TFoo); </div><div><br></div><div>or like this for TObject field for ref. count for ARC:</div><div><br></div></div>[Volatile] FRefCount: Integer;<br clear="all"><div><br></div><div>Note: these attributes are on my TODO list.</div><div><br></div><div>To protect our management operators we should declare in System.pp:</div><div><br></div><div>  FixedAttribute = class(TCustomAttribute); // or SystemInitializedAttribute<br></div><div><br></div><div>Now the <span style="font-size:12.8px">gSomething from example is declared as:</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">var</span></div><div><span style="font-size:12.8px">  [Fixed] gSomething: TSomeType; // fixed can be used only for global variables and for class var/{$J+} const (aka static var)</span></div><div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">... that means "don't' [Initialize|Finalize|FillChar|Whatever] this variable from module but from System.pp (in special table in initialization section)". Any module may contain special hidden section (if [Fixed] attribute is detected); that will register all global variables declared with [Fixed] and any variable with [Fixed] will be excluded from standard initialization/finalization process. That special all "Fixed Sections" from all modules should be called before any other initialize/finalize to register all variables (and before system initialize section ofc, where all registered fixed variables shall be initialized, and after all ofc finalized).</span></div></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">That approach is also usefully to fix existing problems with initialize/finalize (!)</span></div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>Best regards,<br>Maciej Izak</div></div></div>
</div></div>