Hi, Am Sunday 17 June 2007 schrieb Craig Ringer: > Hi all > > I'm hoping for a few design comments on ownership and lifetime issues. > > It's become increasingly clear to me that podofo doesn't need implicit > sharing anywhere except *maybe* PdfStream. In most places, however, the > following rules would suffice, and I'm wondering if you think this is a > sensible approach: > > - A PdfObject is ALWAYS owned by a PdfVecObjects. Users must still be > able to create them in order to permit user subclassses of PdfObject, > but they should be given to a PdfVecObjects. An extensible factory might > be one way to permit PdfVecObjects to create them its self so users can > be prevented from ever being able to do so.
Maybe a factory with a template where T must be a PdfObject subclass is a good
idea: template<class T> T* PdfVecObject::CreateObject()<T>.
Otherwise I agree, it is a sensible approach that PdfObjects are always owned
by a PdfVecObjects. It makes technically sense and it is easy to understand
for the user (every PdfObject is deleted by its PdfVecObjects -> see
PdfObject:GetOwneer() which is right now not always true ).
> - A PdfVariant is owned by either another PdfVariant, a PdfObject that's
> owned by PdfVecObjects, or directly by the user of the library. In the
> first two cases PoDoFo does the right thing and the user shouldn't touch
> the object; in the third, the user who created the object is responsible
> for destroying it. PoDoFo will never take ownership of it, rely on it in
> objects not directly created by the user (like a PdfElement) or destroy
> it. Thus, if the user stores all user-created variants in auto_ptr<> or
> similar, they know their memory management should be correct.
Yes, I agree. But in most cases it should be enough to create PdfVariants on
the stack as they can usually be copied very fast. So not even auto_ptr<>
should be needed.
> - A PdfElement never owns the object it manages. It can be created on an
> already-existing object without problems, and can be deleted without
> affecting the object it manages. It is not legal to delete an object
> before the PdfElement it manages, and doing so will cause undefined
> behaviour. Consequently PdfElements should be cheap to create and
> destroy and should be short-lived; if a PdfElement must be passed around
> or retained, that should be done by passing its underlying variant.
FULL ACK! A PdfElement should never own its object, and the object has to
exists as long as the PdfElement exists.
I am going to commit another change to the PdfField implementation soon. This
change allows PdfFields to be copied very fast (only the pointer to the
managed object is copied) so all PdfFields can live on the stack on no heap
allocation is required. I think we can apply this later to PdfAction,
PdfAnnotation etc. too so that we do not have to keep pointers to
PdfAnnotations like it is done in PdfPage right now.
So I agree, creating, deleting and copying a PdfElement should be fast! One
think that we have to clearly state here is that copying a PdfElement (i.e.
calling operartor= or a copy constructor) does not copy the underlying object
but only the PdfElement you use to access the real PdfObject/PdfVariant).
> In other words, PoDoFo maintains a tree of ownership rooted at
> PdfVecObjects for all PdfObject and PdfVariant instances it creates. It
> never creates a PdfElement; only the user does that to manipulate the
> document tree. Not that dissimilar to how it works now, actually, but
> for a few details.
>
> The current trunk doesn't follow those rules, in that it uses a
> PdfObject for indirect objects not managed directly by PdfVecObjects, it
> holds on to PdfElement instances, and it may hold pointers to
> user-created variants. If you all think all this makes sense, however,
> I'm interested in moving in this direction. I've already done much of
> the required work in a branch by way of investigation.
So, I agree with your mail - thanks for putting so much thought in this stuff
and writing it all together. Regarding the time frame for this, please see my
other mail.
best regards,
Dom
--
**********************************************************************
Dominik Seichter - [EMAIL PROTECTED]
KRename - http://www.krename.net - Powerful batch renamer for KDE
KBarcode - http://www.kbarcode.net - Barcode and label printing
PoDoFo - http://podofo.sf.net - PDF generation and parsing library
SchafKopf - http://schafkopf.berlios.de - Schafkopf, a card game, for KDE
Alan - http://alan.sf.net - A Turing Machine in Java
**********************************************************************
pgpqaXv087qcQ.pgp
Description: PGP signature
------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
_______________________________________________ Podofo-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/podofo-users
