lockfree icon indicating copy to clipboard operation
lockfree copied to clipboard

move only types are not supported

Open tnovotny opened this issue 8 years ago • 10 comments

It is currently not possible to get a move only type into the lockfree datastructures. It leades to compile errors.

tnovotny avatar Aug 01 '16 21:08 tnovotny

for some data structures this is by design (the queue requires a trivial assignment operator) for the other data structures, patches are more than welcome

timblechmann avatar Aug 02 '16 08:08 timblechmann

I patched spsc_queue so that it works for me. I posted about this in the boost mailing list here: getting a move only type into spsc_queue.

In the meantime I forked the repository and have a better implementation that uses std::enable_if. The main "issue" is the "detail\copy_payload.hpp" which is used by serveral implementaions so I'm hesitant to change it.

tnovotny avatar Aug 02 '16 09:08 tnovotny

i'm not reading the boost-user list. but you could do a PR and we could discuss it there

timblechmann avatar Aug 02 '16 09:08 timblechmann

I'll tidy the stuff up a little a locally, push it, and then do a PR.

tnovotny avatar Aug 02 '16 17:08 tnovotny

@timblechmann any news on that ? Thanks !

cor3ntin avatar Dec 28 '17 08:12 cor3ntin

@cor3ntin I made the pull request minimal changes to allow single move only values to be pushed and poped #27 on Aug 3, 2016 and have received no feedback.

tnovotny avatar Dec 28 '17 23:12 tnovotny

thanks for the heads-up.

from the 3 PRs #31 looks best and i'm commenting on this. i only have limited time atm to work on this and no real use-case for move semantics, so it would be great if you guys could pick up that pr and complete it

timblechmann avatar Dec 29 '17 04:12 timblechmann

@timblechmann But they do different things. This one works with move-only types such as unique_ptr where as the other simply does some optimizations for move-able types. #31 but fails on move-only types.

tnovotny avatar Dec 29 '17 08:12 tnovotny

#27 will break c++98 compatibility. any PR that will go in should not break compatibility as it may break user code. move-only types should be supported, though.

i don't care too much, which implementation should go in, as long as it's still c++98 compatible, has test coverage and supports both moveable and move-only types :)

timblechmann avatar Dec 29 '17 08:12 timblechmann

@timblechmann I'm sure #27 can be made c++98 compatible by simply hiding the functionality via #defines. We can also do them one after another, first move-able and then move-only.

tnovotny avatar Dec 29 '17 09:12 tnovotny