I want to use the super handy functions in
<algorithm> with JUCE classes like
ValueTree, but I can’t because their iterators are extremely basic and lack definitions for things like
difference_type. Any chance we can get these so we can leverage the STL’s algorithms from JUCE containers?
I want to use the super handy functions in
What STL stuff does this entail?
edit: I’m a dummy, cppreference ftw:
How about I do some legwork here and you write the UnitTests, @jonathonracz?
Sure! Hit me with a PM or post here when you’ve got something.
I’m in a hurry on this so I whipped up a version for
To the JUCE team: all that needs to be added to make the JUCE iterators
ForwardIterator compatible are
iterator_category. The iterator in the gist above is simply a 1:1 wrapper around
ValueTree::Iterator with those definitions added, and now I’m zooming around in
Not bad! We can make it bidi with a few more methods. If you want to cut some redundancy and make it look more standard, derive the iterator as such:
public std::iterator<std::forward_iterator_tag, void>, and remove your typedefs.
I would’ve but
std::iterator is deprecated in C++17
Why not add the
ValueTree::Iterator directly instead of making a wrapper?
I avoid modifying JUCE library code at all costs so I don’t have to maintain my own branch or otherwise try to keep track of changes I’m making per-project.
Instead, I always try to create workarounds to non destructively extend JUCE functionality so myself and others can easily integrate them. My best (yet unreleased) example of this is my accessibility module, which uses a bunch of clever listener techniques to hook native OS accessibility hierarchies into JUCE’s
So the idea was not to get this contributed into JUCE?
I would be very happy to help you, but like you, I don’t like maintaining my own branch, so I just prefer contributing back into upstream ASAP.
In almost all cases I’ve seen over the years, contributing to JUCE operates at a glacial pace (especially when it’s a feature addition). Additionally, since I’m not a paying customer (just a student who uses it for 100% of my open source/academic work) I’m at the bottom of the pecking order to get the team’s attention.
It’s only like 5 lines of
typedefs, my hope is someone will see it and add it to the
ValueTree::Iterator if they deem it necessary. Since I work 24/7/365 and I can’t move forward until I have this iterator, I went ahead and whipped up a quick workaround.
That’s a bit unfair, we’re often very quick if it’s something straightforward!
Certainly adding some typedefs to ValueTree::Iterator is a good idea, I can do that. I’m guessing that these would be enough for the use-cases that you’ve tested?
using difference_type = std::ptrdiff_t; using value_type = ValueTree; using reference = ValueTree&; using pointer = ValueTree*; using iterator_category = std::forward_iterator_tag;
Yes I am being a bit hyperbolic, if it really was that slow for trivial additions I wouldn’t be sticking around I suppose. I’m aware the JUCE team seems a little understaffed and overworked with demands coming in from ROLI, paying customers, freeloaders like myself.
And yes, those are the necessary typedefs - while I know
using x = y is semantically identical to
typedef, I didn’t try it with that. Knowing how picky extending the STL can be, try tossing it at some
<algorithm> functions to test it out to make sure I didn’t miss anything.
Array and other JUCE containers with iterators could use these at some point - it gets marginally hairier since templated types become involved. Another consideration is that certain algorithms can be made much faster by supporting random access iterators (which from my understanding are a superset of
std::forward_iterator) which would be a nice future addition.
Any news on adding this…?
BTW, I ended up needing these extra traits for the
Array classes too, so I made a set of
Iterator objects for those as well which are almost identical to the gist in my prior post. FWIW I used the
using keyword instead of
typedef and it worked fine (as it should since they’re supposed to be semantically identical).
So long as the definitions are getting added, it would be nice if we could get some iterator qualifiers past the simple
ForwardIterator in. Some algorithms in the STL run faster with
RandomAcessIterator, which I’m pretty sure most JUCE containers qualify for. It’s mostly just a matter of navigating the template jungle to satisfy the right definition requirements.