Breaking Change: JUCE Atomic class

Just a quick heads up that we needed to introduce a breaking change to JUCE’s Atomic class. Before this change the following code would assert:

int i;

int* a (&i); 
Atomic<int*> b (a);

jassert (++a == ++b);

This is because pointer arithmetic would behave differently on real pointers vs. pointers wrapped in JUCE’s Atomic class: Atomic would always increment/decrement by only a single byte. This was not only super confusing but would also lead to un-aligned memory access (for example: *(++a) = 0).

Unfortunately, anybody relying on JUCE’s old and confusing behaviour will need to update their code or risk random behaviour or - worse - crashes.

1 Like

If C++11 becomes mandatory for Juce.
Maybe you guys should deprecated all the stuff which are now in the standard library, no ?

Yes, the motivation for this change is to make JUCE’s Atomic class be a simple wrapper around std::atomic on platforms that support this. This is why we needed to make this breaking change to align their behaviour.

7 Likes

Can we rely on y’all to have gone through the JUCE code base and fixed any use of the Atomic class to address this in the JUCE code?

Cheers,

Rail

Of course!

1 Like

That’s great!

With this commit JUCE’s Atomic class is now a wrapper around std::atomic on supported platforms. The Atomic class methods simply call the corresponding std::atomic method so it should be backwards compatible, with the exception of the Atomic::compareAndSetValue() method which has been deprecated as std::atomic does not have an equivalent.

1 Like