On Aug 12, 2009, at 8:41 AM, Krzysztof Kosiński wrote:
Here is my idea. We define a three-way smartpointer that looks like this:
Well... first I'd avoid calling it a "smartpointer". That tends to wander into existing terminology for things that are very often poorly used.
Why this is better than keeping pointers to the references in std::list or
std::vector?
- no memory allocations when adding a reference = better performance.
That may or may not be true. However the bottom line for performance items is to get solid metrics before and after. Also a key is to only optimize something that is shown to be a performance bottleneck.
Unfortunately I've often seen micro-optimizations lead to macro-degradation.
- removing a reference is much simpler, because finding it in the list is
not needed.
- signals can be put in the ObjectRef class.
- simple and elegant implementation.
Some of the issues are nice. However the overall impression I get here is of a system that breaks encapsulation. We should look to use this more in a situation where "smaller" owned things do not know about things that own them, etc.
While it does strike me as good code, it also looks like a less-than-efficient algorithm/architecture.
The signals part also raises some major issues. At the moment we have two trees of data (SPObject *and* xml repr) that tend to get out of sync. Among other things there are several layer bugs related to that. What we probably should focus on is a higher level solution that accounts for the two parallel trees, signals, event bubbling, even canceling, etc. I think that will bear more long-term fruit.
Also it is good that you've seen the id's as a problem. The code early on needed to put an id attribute on every single XML element. We have cleaned up much in the code and should be able to further attack things on that point. Why is this pertinent? Well, if one has id's on everything then then ID changing and clash prevention is a huge problem. However, if instead of having thousands of IDs in a document, one only has a dozen then the problem is a completely different one, with different parameters, scaling needs, etc.
I guess what I'm trying to point out is that instead of focusing on an optimized list structure, we need to look at an efficient overall solution for the whole use case of Inkscape, including parallel data trees, shadow trees, event propagation life-cycles, etc. Then as we drill-down on the larger problem, we might hit on tunings to use this data type. Or we might see a need for a few similar-yet-distinct types.