Thanks, yes I am, although the result is consistently problematic with various older versions of the toolchain components too. I’m on Windows 10.
It seems that the issue continues to be whether or not an “Android”
int is lock-free for atomic operations, as demanded by
ReferenceCountedObject. The standard library is certainly bringing this into question, and I suppose some of the many Android architectures may not come to the lock-free
int party. As a result, JUCE is complaining about this lack of guarantee, so it’s clearly a problematic assumption on some level. Meanwhile I have commented out this single
static_assert and everything works fine for me on the few platforms I have tested, but they all feature atomic
int operations anyway.
I suppose my main question is: do operations on
int really need to be absolutely guaranteed lock-free for
ReferenceCountedObject to function correctly, to the point where it forces a build to break? Are there certain deadlock-style situations to guard against due to its design or is it simply a performance concern? And if it is a serious problem, could we fall back to a smaller-sized numeric value, as code that has hundreds or millions of references to a single object is probably broken in some other way? This whole discussion feels like overkill though!
In any case, I would be happy with some minor spinning on certain platforms if it means the code will actually compile on any of them. Of course it would be nice to standardise reference counts over to
shared_ptr which would render this whole discussion moot; I see there is a move in this direction already so I’m keen to see how it plays out in the long term.