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.

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

| 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'*

-- 
        Lgb

Reply via email to