Cleaning up Fl_Text_Buffer

[Rob McDonald]

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?

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?

Rob

[Albrecht Schlosser]

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.

[Rob McDonald]

On Saturday, December 25, 2021 at 6:05:41 AM UTC-8 Albrecht Schlosser wrote:

> 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.

Thanks for the confirmation -- that is pretty much the understanding I had come to.

FLTK has no guarantees about a particular buffer being paired to a particular Display -- but in my application, I can have such guarantees.

Rob