<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-04-11 14:38 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>There is another problem that occurred <a href="http://to.me" target="_blank">to.me</a> after my previous mail. Have you ever heard of the "static initialization order fiasco"? I've stumbled upon that a few weeks ago at work with C++ and was glad that we don't have that problem in Pascal, but with the new management operators and the need to have global variables be initialized correctly as well this would change - which would be very bad as this is a hard to debug problem.<br></p></span></blockquote><div>Even worse, currently is possible to achieve some similar... I've experienced from another side - "static finalization order fiasco" for Generics.Collections (fixed 24 Dec 2015 <a href="https://github.com/dathox/generics.collections/commit/fda586932bd80ef58c08f8ebf5a24316ca4ccca5">https://github.com/dathox/generics.collections/commit/fda586932bd80ef58c08f8ebf5a24316ca4ccca5</a> ). </div><div><br></div><div>I can confirm that "static initialization/finalization order fiasco"  bugs are really hard to debug. In my case for Generics.Collections was something like this (maybe not the same but very similar):</div><div><br></div><div>=== X ===</div><div>program X;</div><div><br></div><div>uses</div><div>  UnitA, ..., UnitZ, GC, Generics.Collections, Unit1;</div><div>...</div><div>=== GC ===</div><div>...</div><div>interface</div><div>var</div><div>  G: Contnrs.TObjectList;</div><div>implementation</div><div>...</div><div>initialization</div><div>  G := Contnrs.TObjectList.Create(True);</div><div>finalization</div><div>  G.Free; // !!! </div><div>end.</div><div><br></div><div>=== Unit1 ===</div><div>... somewhere in code ...</div><div>var</div><div>  d: TDictionary<string, string>;</div><div>begin</div><div>  d := TDictionary<string, string>.Create;</div><div>  G.Add(d);</div><div>=== END CODE ===</div><div><br></div><div>at line marked by "!!!" was memory corruption, because any of manual interface used by dictionary was already destroyed in static/class destructor in Generics.Defaults... Really hard to find that kind of bug. What was funny the corruption was visible only on android... Anyway bug is fixed :) </div><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></p></span><p>
I'll provide you with an example when I'm back home again in the evening.</p><span class="">
<p>> Sven, could you look at topic "Management operators AddRef and Copy vs Copy" thread? New operators are ready for test in branch, anyway we can adjust the naming of AddRef and Copy. Florian proposed "Clone" (instead of Copy) and "Copy" (instead of AddRef).</p>
</span><p>I've yet to find a quiet minute to digest that one :P</p></blockquote><div>Ok! Thanks. I'm looking forward :P</div></div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>Best regards,<br>Maciej Izak</div></div></div>
</div></div>