Give nsTObserverArray standard iterator types
Categories
(Core :: XPCOM, enhancement, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox79 | --- | fixed |
People
(Reporter: ehsan.akhgari, Assigned: sg)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
Comment 1•7 years ago
|
||
Updated•7 years ago
|
Assignee | ||
Comment 2•4 years ago
|
||
(In reply to Eric Rahm [:erahm] from comment #1)
This is a bit tricky since we support mutating the array during iteration.
We have a couple types of iterators in there, ForwardIterator and
EndLimitedIterator, that behave differently depending on mutation behavior.
That's not a fundamental issue for providing standard iterators. They could be returned by non-standard member functions, e.g. forward_begin, forward_end, end_limited_begin, end_limited_end
.
Only if we want to be a Range (and support range-based for), we would need to decide which of these iterator flavours should be used for that. If we think the user needs the choice, we could provide them via a simple wrapper type templates such that one could write:
nsTObserverArray<Foo> array;
for (const Foo& foo : ForwardIterated(array)) { ... }
for (const Foo& foo : EndLimitedIterated(array)) { ... }
with (just a sketch)
template<typename ObserverArrayT> struct ForwardIterated {
// maybe define value_type etc.
ForwardIterated(ObserverArrayT &aArray);
auto begin() { return mArray.forward_begin(); }
auto end() { return mArray.forward_end(); }
private:
ObserverArrayT &aArray;
};
They also require that
HasMore
is checked before retrieving the next item.I'm not even sure how we could define
end()
in this case.
A Range can now have different types for begin and end iterators, maybe this could be exploited here.
Range-based for also allows for that with C++17.
Assignee | ||
Comment 3•4 years ago
|
||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 5•4 years ago
|
||
bugherder |
Description
•