FYI, updated again. I've cleaned up the code a bit: - Provides allocator_type typedef and get_allocator() method per AllocatorAwareContainer requirements. - Uses allocator_traits construct/destroy only for the original type T, per AllocatorAwareContainer requirements. (Since apparently people get grumpy when also used for node types.) - Adds constructors to accept a stateful allocator instance (although mpmc_bounded_value has a required max_size parameter, so doesn't exactly fit the concept). - Stores only one copy of the allocator instance (since I have been assured that it's legal to call construct for type T on an allocator instance for type X). - Uses addressof with T, so works as expected even if T overrides operator&.
I think this is probably as close as it can get to AllocatorAwareContainer. It is neither movable nor copyable (due to atomics) so does not implement those requirements, and does not implement the initial-insertion constructors (as that would be a very weird use-case for an atomic queue). On Thursday, February 16, 2017 at 6:43:53 PM UTC+13, Gavin Lambert wrote: > > FYI, I've updated the code a little; I noticed I accidentally omitted two > BOOST_NOEXCEPT_EXPR required to compile on compilers more modern than > VS2013. > > Given the lack of response, though, I guess nobody's interested after all? > > On Tuesday, November 29, 2016 at 5:03:52 PM UTC+13, I wrote: >> >> On Friday, November 25, 2016 at 6:08:48 PM UTC+13, I wrote: >>> >>> If either of you are interested, I have an adaptation of the queue which >>> supports allocator_traits, movable types, and exception safety (basic or >>> noexcept, as appropriate, and BOOST_NO_EXCEPTIONS). >>> >>> It assumes at least C++11, though. (Or technically, almost-C++11, since >>> it's mostly tested in VS2013.) >>> >> >> Have a look: >> https://gist.github.com/uecasm/b547db812ae4bba39bb1bd0443801507 >> >> (I marked it as secret just so that people don't stumble across it >> without the context; I don't mind it being used.) >> >> I'm not 100% certain I have the allocator_traits officially correct (and >> I've omitted some constructors that would be required for stateful >> allocators that require initialisation), but it seems to work as expected. >> >> With BOOST_NO_EXCEPTIONS defined the noexcept vs. except implementations >> end up being largely identical, although it will still exercise both paths >> depending on the declared types. Didn't seem worthwhile chasing the tiny >> size optimisation that could potentially result from being aware of this. >> A sufficiently clever compiler might do it itself, although it would >> surprise me. Similarly mpmc_fixed_bounded_value could avoid the heap >> allocation if written differently, but sometimes that's not a good thing. >> > -- --- You received this message because you are subscribed to the Google Groups "Scalable Synchronization Algorithms" group. To unsubscribe from this group and stop receiving emails from it, send an email to lock-free+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/lock-free/f8b73632-8631-4f36-96ab-3ea5418b5a5a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
