Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
|
| > | > | + lyx::frontend::WorkArea * work_area_;
| > | > Do we want bald pointers? Even just as cache?
| > | | I can't use reference because I want to be able to change
| > work_area_
| > | at run-time. This work_area_ is not created nor deleted here so it is
| > | a _safe_ use of pointer. Feel free to suggest something else that
| > | retain polymorphisms.
| > boost::shared_ptr<lyx::frontend::WorkArea, no_delete> work_area_;
|
| IMO, this is just noise. This work_area_ is already enclosed in a
| shared_ptr (look at TheGui.[Ch]). What's the use of this shared_ptr
| here? What's wrong in passing a pointer if we know exactly where it is
| created and deleted (and nowhere else)? Are you affraid of some hacker
| doing a "delete work_area_" somewhere?
Kindo, but not exactly. My problem is that I cannot see from a bald
pointer how to treat it. Should I manually delete it? should I just
let it go out of scope, wont't that leak memory? To answer these
questions I have to trace back where the variable comes from. IMHO it
is a lot better to annotate varibles in such a way so that such
question is trivially easy to answer by just looking at the variable
definition.
And if work_area_ is alread a shared_ptr, then IMHO that should be
used or a weak_ptr.
I'll look at weak_ptr after the change.
| Please No. The views will be part of TheGui in my next cleanup round
| (see already sent patch). Ultimately I want only one global variable:
|
| Application * theApp;
Another bald pointer?
Yes. There is only one Application instance created in lyx_gui.C::exec()
Note that, in a Qt program, there is already a qApp global pointer that
points the unique QApplication. Everywhere in the code you can access to
it. As Application derives from QApplication, I can remove this global
pointer and use a static_cast to qApp instead anywhere in the code:
Application * theApp = static_cast<Application> qApp;
But I think it is much cleaner to define the global pointer.
| TheGui will be accessible through theApp->gui();
|
|
| > but it is the class name that is vague... hmm... even MainGui is
| > better imho. (MainGuiClass)
|
| IMHO MainGui is wrong because there shall be just one unique Gui,
| MainGui suggest that there could be more than one. Please Note that I
| have change the naming 4 times already and I've asked repeatedly your
| opinion about that.
Been busy.
*but I really dislike 'TheGui'*
Propose something else then:
UniqueGui
UniqueGuiInstance
GuiImplementation
GuiInstance
LarsGui
LyXGui
GuiGui
MyGui
MyGuiIsBig
...
If you really insist I will use MainGui because the kernel won't see it
anyway and the rest will just use "theApp->gui()".
Abdel.
