25.02.2013 3:59, monarch_dodra пишет:
I don't see any any calls to remove, so I'm not sure what the algorithm
is. Wouldn't patch just grow and grow and grow?
Regardless, the design of DList is currently flawed (but a pull is open
to fix it), in the sense that a DList is just a "handle" on a chain of
nodes.
The problem with this approach is that calls to things such as
"removeFront()" or "removeFront(n)" merelly reposition the "first"
pointer. However, the nodes are never actually un-linked. I'd say there
are good chances this is what you are seeing.
Seeing a DList doesn't have splice either, I'm unsure what to tell you
in regards to working around it.
I'd say once you are done with a list, you can try to "dup" it: This
will allocate *more*, but will allow the GC to collect everything that
was previously removed.
...Or just SList. It's "less" bugged.
See this:
http://forum.dlang.org/thread/gjhclwsuqyhrimdeo...@forum.dlang.org
After some research I think that this situation is due to several
reasons set and DList isn't single cause.
patch is local var:
class DataChunk {
uint source_id;
uint id;
...
}
class DataStorage {
DList!DataChunk patch;
(RedBlackTree!DataChunk)[uint] _container_map;
...
auto getPatch(uint source, long last) {
bool isNewer(DataChunk dc) {
if(dc.source_id == source && dc.id > last)
return true;
else
return false;
}
Patch patch;
foreach(datachunk; find!isNewer(_container_map[source][])) {
patch.insertFront(datachunk);
}
}
}
so it doesn't grow.
