Mailing List archive

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

[vdr] Re: OSD and patterns



Jouni Karvo wrote:
> 
> hello,
> 
> Klaus Schmidinger writes:
>  > > Another thing that came to my mind is to use the proxy pattern as an
>  > > intelligent pointer for cOsd so that the user of the OSD would not
>  > > need to take care of explicitly deleting it but it would be deleted
>  > > automatically whenever no-one has a pointer to it any more.  I'm not
>  > > sure if this is the best thing to do in this case, but if you are
>  > > interested, I could try to find time to provide a patch for it.
>  >
>  > Since at any time only the one who has actually created a cOsd should
>  > have access to it, this approach would be feasible.
> 
> I looked at this, but it seems it needs a bit more thought.  The
> "cOsd *":s are used extensively as class members and I do not know if those
> classes are supposed to outlive the osd.  (The "cOsd *osd" would need
> to be replaced with "cOsdPtr osd" and that would mean that the osd
> would be deleted when all the classes having the pointer are deleted,
> and no pointer is left.  Using "cOsdPtr *osd" would make the whole
> thing useless.)
> 
> Also, it seems that "delete osd" is used for two purposes: actually
> deleting the osd (at least in DvbSpuDecoder::Hide) and for the memory
> cleanup purpose.  If the smart pointer implementation would be used,
> these cases need to be differentiated.  The pattern takes care of
> memory management by itself and delete commands can be removed, but
> then an explicit osd shutdown is needed.

Take a look at how, for instance, cSkinClassicDisplayChannel does it.
It creates a cOsd object in its consructor and deletes it in its
destructor. Since at any time there is only one cSkin* object alive,
this is an easy to follow rule.

At no time is there more than one object that has direct access to
any cOsd object, so there is no need for a "pattern" as you described it.

Klaus




Home | Main Index | Thread Index