FLTK logo

Re: [fltk.general] Cleaning up Fl_Text_Buffer

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.general  ]
 
Previous Message ]New Message | Reply ]Next Message ]

Re: Cleaning up Fl_Text_Buffer Albrecht Schlosser Dec 25, 2021  
 
On 12/25/21 12:48 AM Rob McDonald wrote:
I have a class derived from Fl_Double_Window.

That Fl_Double_Window has a Fl_Group that ends up holding an Fl_Text_Display.

The class also has a Fl_Text_Buffer associated with the Fl_Text_Display.

I am working on the destructor for my class.

If I call delete on the Fl_Text_Buffer, then the Buffer is destroyed before the Fl_Text_Display destructor gets called (through the Fl_Double_Window and Fl_Group destructors).

I've tried setting the Fl_Text_Display's buffer to NULL before destructing the buffer.  This seems to 'work', but also seems extremely hacky.

Foo::~Foo()
{
    m_Display->buffer( NULL );
    delete m_Buffer;
}

Is this the proper way to clean up in this situation?

Yes, I think this is the correct solution. Think about the way you create the two objects (Fl_Text_Display and Fl_Text_Buffer) and then connect them. Destroying them correctly would be the opposite order: break the connection, then delete the two objects. Since Fl_Text_Display and Fl_Text_Buffer are independent of each other the order wouldn't matter.

However, if you deleted the Fl_Text_Display object first it should work as well because it would break the connection in its destructor. The only thing you must not do is to delete the Fl_Text_Buffer first while it is still asscociated with the Fl_Text_Display.

I might be able to make the Fl_Text_Buffer a direct member variable (instead of a pointer allocated with new), but I can still imagine situations where this would arise.

Am I missing something?

Not really AFAICT, but remember the fact that one Fl_Text_Buffer can be associated with more than one Fl_Text_Display or Fl_Text_Editor at the same time or of course one after the other with the same Fl_Text_Display. There's no automatism to destroy them together because there's no "ownership". The Fl_Text_Buffer does not even "know" that it is associated with one or more Fl_Text_Display's.

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/d433ccea-b19c-ab43-5b8b-f23f78c05abf%40online.de.
Direct Link to Message ]
 
     
Previous Message ]New Message | Reply ]Next Message ]
 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.