Cameron
This indeed would not be very accurate. In particular, size_approx can temporarily return a count larger than the actual number of queued elements. There's also a race where multiple threads...
I believe the inaccuracy would be driven primarily by the number of threads accessing the queue, plus the latency between the values seen by one thread versus the "current" value,...
Sorry, not going to add such methods as I believe they'd be more misleading than helpful. The error bounds would be quite large.
IMO silently undefining a system macro would be far more confusing. I could add an `#ifdef #error` but then the user still wouldn't know where the macro is defined.
Looks like I could use push_macro/pop_macro to avoid this for GCC and clang within the header itself. But it's not really improving anything, just hiding it. Also clang's implementation of...
If you do get it working on QNX, feel free to open a pull request.
It doesn't use standard allocators or throw `std::bad_alloc` if that's what you're asking, but you can customize the allocation through the traits. The default is malloc/free.
Oops, was thinking of my MPMC implementation. `ReaderWriterQueue` also uses `malloc`/`free` and does not throw `std::bad_alloc`, but provides no customization point for changing the allocation implementation.
This should not happen. Can you share example code that reproduces the issue?
Nothing stands out as problematic with this code (besides the call to `enqueue` within an `assert`). Can you add a `main` to this example that reproduces the issue?