On Tuesday, 24 November 2015 at 19:22:46 UTC, bitwise wrote:
On Tuesday, 24 November 2015 at 18:22:12 UTC, duff wrote:
On Tuesday, 24 November 2015 at 17:03:47 UTC, bitwise wrote:
Then, during recursive serialization, if you found an object
which was already in the table, you wouldn't serialize it
again.
But this doesn't give the guarentee that the real citizen who
responsible to tell the client "hey i've got the ref" can do
it. With RC, the real owner may not know that his resource is
stolen by a children.
The way that I was dealing with this at the time was requesting
resources(files) from a shared repository by name. The
repository would either load the file and instantiate the
appropriate object, or return the object if it already existed.
So, no node in the graph ever really owned a resource. All
resources were owned by one central repository. Now, this was
only enforced by convention, so I suppose someone could call
delete on the shared_ptr's internal pointer, but making this
strictly enforced through language features is difficult, if at
all possible without major comprimises.
There is some discussion about this idea in the dlang Study
forum. They're trying to figure out how to implement ref
counting in D in a totally @safe way(impossible to currupt
memory). I think that some major comprimises will have to be
made, and I personally wohld rather deal with this issue
through good coding conventions.
Bit
I should add that the repository stored references to the
resources as weak_ptrs so when the resources went out of scope,
they would be deleted. Similar systems may also choose to keep
these resources around, even with a ref count of zero, and only
delete them when more new resources were requested and memory ran
low. This would be a much more comicated approach though.
