On Sun, Nov 6, 2016 at 2:47 PM, Miral Mirality <uec...@gmail.com> wrote: > On Monday, November 7, 2016 at 5:07:24 AM UTC+13, Dmitry Vyukov wrote: >> >> The best solution would be to require copying of elements to not >> throw. One way to achieve that is to create a copy of the element >> beforehand and then use moving constructor to move it to the queue. >> Move constructors should not allocate. > > > While that's preferred, you can't assume this in generic code. In fact as > far as I know there's no way to tell in generic code whether a given > move-construction expression actually calls a move constructor or whether it > calls a copy constructor, and you'd generally expect the latter to be able > to allocate, which implies it can throw. > > Although you can generically test whether a move-construction expression has > been declared as noexcept, which helps differentiate things if (as is > usually expected) the copy constructor can throw and the move constructor > doesn't. But this isn't actually required and it's probably still rare for > user (and many library) types to have noexcept specified.
Well, if you want all the fancy staff just in case, I guess you need to use a mutex. It does not scale, but in return you have the fancy staff. Your choice. I would just require the copy to not throw. If it's not check-able, fine, there are zillions of things in programming that are not check-able. You can't prevent user from shooting himself in a foot. -- --- 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/CAEeQi3sBXM2zhpkOivsBLj0Z%3DaP3%3DOEx_f%3DRJM_Lb1_ArqOAHQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
