[fpc-devel] Initialize/Finalize management operators and Default intrinsic

[Florian Klämpfl]

Am 12.04.2016 um 23:10 schrieb Sven Barth:
> On 12.04.2016 21:12, Florian Klämpfl wrote:
>> Am 12.04.2016 um 08:57 schrieb Maciej Izak:
>>> 2016-04-11 23:36 GMT+02:00 Sven Barth <pascaldragon at googlemail.com
>>> <mailto:pascaldragon at googlemail.com>>:
>>>
>>>     I know this is a rather constructed example, but it's similar to the C++
>>>     code we had at work, so it's code that can happen in the real world.
>>>     If we don't find a way to solve this problem then I'm afraid that I
>>>     won't include your changes in trunk, cause I don't want to open that can
>>>     of worms.
>>>
>>>
>>> Eeeee? I am a little shocked by your arguments because that kind of bug is possible since we have
>>> initialization/finalization section and uses section in interface/implementation section. *The
>>> programmer must be aware of*. The mentioned bugs are here a looong time. For example fixed by me for
>>> Lazarus:
>>> http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision&root=lazarus&sortby=date&revision=49547
>>>
>>
>> I agree with Maciej here: this kind of stuff can also happen with normal initialization code and
>> uses of units in the implementation part. In this case the programmer must simply be very careful.
>> Though in your example I think unit1 is always initialized first as it does not depend on unit2. The
>> problem might pop up though if you use unit2 in the implementation part of unit1.
> 
> In that specific example you would be right, but units are seldomly used
> in isolation and once both unit1 and unit2 are used in more units it
> isn't that clear (to the user) anymore which unit is initialized first.

In case of usage through the uses in the interfaces, it is clear. A used unit is initialized before
the unit which uses it.

For uses by the implementation section the initialization order is undefined especially in case of
circular dependencies. There is no way round.

> As I wrote in another mail a good solution would probably be for these
> kind of global variables to be initialized after all initialization
> sections have run and to have that documented like that. This way we
> avoid adding *another* potential pitfall with unit initializations.
> Functions that use such global variables could have a flag added which
> gets added recursively and thus we could warn in the initialization
> sections if such routines are used nevertheless.
> The latter could be also done in case we indeed don't do anything
> special with these records. This way the user would at least be warned...

Just make a simple rule: custom managed types are initialized directly before or after (to be
defined but I prefer before) the initialization part of the unit is run.