On Tuesday, 24 November 2015 at 19:37:33 UTC, duff wrote:
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 know that there is a study group.
And it's not the first time I post this:
http://www.reactiongifs.com/r/dnd.gif
because manual memory managment is the stuff.
I had my way, the first thing I would do is get rid of @safe and
shared ;)
Its not that I don't think the general idea of making the
language safe is good, but there is just so much that can go
wrong in a systems programming language, its like throwing
glasses of water at a burning house instead of just calling the
fire department..
Never underestimate the resourcefulness of a bad programmer!
