octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #56097] unlink ("filename") hangs GUI


From: John W. Eaton
Subject: [Octave-bug-tracker] [bug #56097] unlink ("filename") hangs GUI
Date: Thu, 11 Apr 2019 12:56:11 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0

Follow-up Comment #37, bug #56097 (project octave):

I don't see performance as an issue here.  More important to me is avoiding
these kinds of errors in the future.

Whether we use #ifdef or run-time conditionals, they are not a great solution
because in all places where it is used, we have to remember to check that
m_editor_window is valid.  This requirement is not shared by other objects and
I don't think we want to clutter the code with unnecessary checks on pointers
that we know will always be valid for the life of the object.  Because most
objects are always valid, it is easy to forget to check the ones that might be
NULL.

Another option is to always create the editor window object so, like other
sub-window objects contained in the main_window object, it can be assumed to
exist.  If the editor window doesn't actually provide an editor, it could just
be a text a text widget that displays the message "To provide a functional
built-in editor, Octave requires QScintilla."

Maybe we should adopt this approach as a coding guideline for the GUI so that
we avoid the confusion of having some objects that can be invalid.

We recently had another similar bug with dereferencing a NULL pointer when the
help engine is not available (bug #55736).  It seems to me that our code would
be more reliable if, instead of having to protect m_help_engine (or
m_editor_window) with #ifdefs or run-time conditions, we ensured that these
objects were always valid.  It would also be nice if we could use references
for them (by definition they are always valid) but I don't think Qt allows us
to do that.

This bug report is kind of an obscure place to have this discussion, so maybe
we should move it to the mailing list?

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?56097>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]