David Blaike suggested this as an alternative to the use of owningptr(s) for our
memory management, as value semantics allow to avoid the additional interface
complexity caused by owningptr while still providing similar memory consistency
guarantees. We could also have used a std::vector, but the use of std::vector
would yield possibly changing pointers which currently causes problems as for
example the memory accesses carry pointers to their parent statements. Such
pointers should not change.
Details
Details
Diff Detail
Diff Detail
Event Timeline
Comment Actions
Looks great - deque's a great option (imho - opinions vary, of course) when you're never removing things but are adding new things that all need consistent pointer identity.
Comment Actions
I think this is much more intuitive than the smart pointer version.
If you do only worry about the order but you would like to use a list, define the begin()/end() function of a Scop as rbegin()/rend() of the underlying list of scopstmts, that should give us the same order but avoid the deque (which isn't that bad I guess).
lib/Analysis/ScopInfo.cpp | ||
---|---|---|
2024 | Why no const &? |
Comment Actions
I decided to stay with the deque as the use of rbegin()/rend() is possible, but would (only slightly) increase complexity. As I doubt this has any performance effect, I decided to minimize complexity.
lib/Analysis/ScopInfo.cpp | ||
---|---|---|
2024 | Changed. |
Why no const &?