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. - 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. - 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. 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. -- Craig Ringer ------------------------------------------------------------------------- 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
