I realize the JUCE library purposefully avoids using the STL, but wouldn’t it make sense if the CodeDocument::Iterator was compatible with the STL bidirectional iterators? I’m saying this because I find myself writing a large state machine for the tokenizer, where I would usually just use std::regex and be done with it in 2 minutes. Perhaps there’s some workaround?
Hmm… Well, there are plenty of places in juce where STL iteration would make sense, but I’m surprised that you’d suggest the CodeDocument iterator… It was never really designed to fit into anything else at all, it’s quite a special-purpose object!
I’ve never looked at how std::regex integrates with iterators, but if you have any suggestions for changes that’d make it work, I’m happy to consider them!
Making the iterators STL-compatible was easy enough, but actually making them work with the regex functions is much harder than I thought, since it requires a custom regex_traits class for juce_wchar. If I manage to get it working, I’ll post the code as it could be a big step towards making JUCE strings in general usable by the regex functions.
Thanks! But do bear in mind that anything I add has to also be compatibile with older compilers, so it can’t involve any C++11 classes or features.