Hi,
Sorry for the confusion, I was trying to illustrate the behavior in the simplest terms
If you read my original post:
Database std::shared_ptr that is deleted in the dtor
only the Database is deleted when ref count reaches zero.
Dbobject is a std::shared_ptr that calls ptr->close() in the dtor
It’s not deleted; I’m only managing the state of the object in the dtor, Dbobject is an object that can live in multiple states
- kClosed = no readers or writers
- kForRead = the system allows for 256 simultaneous readers.
- kForWrite = the system allows for 1 simultaneous writer.
- kForNotify = DbObject can wait for a notification of a change in one of the above states
if you imagine drawing a bunch of lines and circles in CAD, the Database is the drawing, Dbobject is the line or arc, or block of text.
They are never deleted, only can be flagged as erased, this way the user can undo/redo.
If you look at my original sample, I’m opening a Database.
I open some DbObjects (Curve) kForRead, collect some data, then notify the Database the object wants to be closed.
The problem was the Database was already deleted because of the destruction order. (exception time)
Most of the time existing DbObjects are opened for read, since the system can have 256 readers, dtor or GC timing is not critical. Any writer can just wait for a notification
As I had mentioned, it’s an edge case. Most Databases are owned by the Document, That’s what’s visible to the user’s drawing area.
In this case, the Database dtor is a noop, it’s all managed in CAD. However, I want to allow users to scan through .dwg files to collect data, blocks of texts, then use the power of Python to do analysis on the data, pandas and what not.
Anyway, the issue has been solved, I hope it explains it a bit better