🚀 go-pugleaf

Ops, I forgot.

On finalization section you must dispose de _Services the same way you 
do it today.

Carlos Alberto Costa Beppler wrote:
> Why not move your initialization code to the GetService procedure?
> 
> It will like this:
> 
> function GetServices: TServices;
> begin
>   if _Services = nil then begin
>     // Set up services: stored in global var in implementation section
>   end;
>   Result := _Services;
> end;
> 
> It will have the advantage of not run the initialization unless it is 
> necessary.
> 
> If you use threads in your code you could write like this:
> 
> var Mutex: TCriticalSection;
> 
> function GetServices: TServices;
> begin
>   if _Services = nil then begin
>     Mutex.Enter;
>     try
>       if _Services = nil then begin
>         // Set up services: stored in global var in ...
>       end;
>     finally
>       Mutex.Leave;
>     end;
>   end;
>   Result := _Services;
> end;
> 
> initialization
>   Mutex := TCriticalSection.Create;
> finalization
>   FreeAndNil(Mutex);
> 
> 
> Gerrit Beuze wrote:
> 
>> Hi all,
>>
>> I have been using dcc32 for years to build final builds.
>> But currently I'm running into an odd problem:
>>
>> When I build an executable (.dpr) with Delphi 7's dcc32.exe the resulting
>> executable has a different unit initialization / finalization order
>> than the same project build from within the IDE.
>>
>> In fact: the version as build with dcc32 crashes because
>> the initialization section for a unit B that "uses" unit A is called
>> BEFORE the unit A initialization section. unit A obviously
>> does not "use" unit B, neither any other units that indirectly use 
>> unit B.
>>
>> I noticed this in several places:
>> One begin very odd where unit A defines an ancestor class and unit B 
>> contains a descendant
>> Even here unit B is initialized BEFORE unit A.
>>
>> In this case too: built with IDE initialization order is as expected, 
>> builr with dcc32 gives bad order.
>>
>>
>> And of course: the same problems occur in the finalization calling order.
>>
>>
>> The basic units layout is like this:
>>
>> unit A;
>>
>> interface
>>
>> uses Classes etc;
>>
>> type
>>   TServices = class (blablabla);
>>
>> function GetServices: TServices;
>>
>> implementation
>>
>> function GetServices: TServices;
>> begin
>>   Result := _Services;
>> end;
>>
>> var
>>   _Services: TServices;
>> initialization
>>   // Set up services: stored in global var in implementation section
>> end.
>>
>> ===================
>>
>> unit B;
>> interface
>> uses unit A;
>> implementation
>> initialization
>>   GetServices.Something; // CRASH!!
>> end.
>>
>>
>> I made sure all compiler settings (D-, C- etc. are defined
>> identical in the project's config file that's used to build with dcc32.
>> All relevant units are in the same directory, so it's not a search 
>> path problem.
>>
>>
>>
>> Questions:
>>
>> #1 : Any idea what's causing this?
>>
>> #2: Any workaround - = how to force module initialization orders ?
>>
>> And no: I cannot provide a small reproducable case.
>>
>> Thanks in advance,
>>
>> Gerrit Beuze
>> ModelMaker Tools
>>
>>