🚀 go-pugleaf

Dan Mayo <do_not_spam_dmayo2@netzero.com> wrote:

>> I'd be very tempted to let it leak. Yes, leaking is usually bad news,
>> but a once-per-program leak is (assuming no weird transactions are
>> expected during cleanup) not normally a problem. Except that CodeGuard
>> will moan. So:
>> 
>>   void __fastcall TForm1::Button1Click(TObject *Sender)
>>   {
>>     static TForm* subform(new TForm(this));
>>   }
>> 
>> End of lifetime with forms can be a problem.
>> 
>
>So the exception reported when the static case of a form above is used 
>is a fact-of-life?

You shouldn't have an exception reported except by CodeGuard, and that's
only because it doesn't realise you accept the leak.

Although the language can initialise something the first time into a
scope, it has no way of knowing when the last occurrence is, only being
able to note after the fact that no more occurrences have happened. 

>BTW, in this case, CodeGuard doesn't moan; the program reports an 
>exception error and the pc politely asks me if I would like to email 
>bill gates with the details.

Ah, now that's a different matter. If you have something getting unhappy
outside main(), there's not much you can do about it.

(Unless it's CodeGuard attempting to make a report, and itself being
buggy. That's very plausible - I have code that runs beautifully for
weeks on end with CodeGuard disabled, but that crashes and burns with
CodeGuard turned on. That's why I have three build configurations -
Debug, Release and CodeGuard - the last that I only use when I'm
explicitly looking for leaks and the like.)

You could try:

  TForm* subform = NULL; // not an ownership pointer

  int main()
  {
    std::auto_ptr<TForm> local_subform(new TForm(NULL));
    subform = local_subform.get();
  }

  void __fastcall TForm1::Button1Click(TObject *Sender)
  {
    // Use subform
  }

It's messy, it uses a global, but it would restrict the object lifetime
to that of the main() function.

Better though, if TForm1 stays around, make the sub form a member of
TForm1. That'd restrict it to a tighter lifetime, one that doesn't
extend beyond that of its parent. It'd also keep its accessibility
restricted to that of the owning object - again a good idea. It also
stops it being a singleton, and singletons are another thing that
indicate potential design problems.

(I should have suggested that earlier - my apologies, it's all to easy
to forget to stand back and look at the grand design.)

Alan Bellingham
-- 
10th Anniversary ACCU Conference: 11-14 April 2007 - Oxford, UK
(Booking now open: see http://accu.org/index.php/conferences for details)