Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

minimal changes to allow single move only values to be pushed and poped #27

Closed
wants to merge 4 commits into from

Conversation

tnovotny
Copy link

@tnovotny tnovotny commented Aug 2, 2016

I have tried to keep the changes minimal.

@tnovotny
Copy link
Author

Any feedback would be appreciated.

@tnovotny tnovotny changed the title minimal changes to allow single move values to be pushed and poped minimal changes to allow single move only values to be pushed and poped Sep 5, 2016
@tnovotny
Copy link
Author

@timblechmann any feedback appreciated.

@timblechmann
Copy link
Collaborator

let's focus on #31 (this one breaks c++98 compatibility btw)

@tnovotny
Copy link
Author

@timblechmann this should not be closed as this PR enables different things than #31. I think after over a year of waiting you should invest more time than to just close it. This one is not 'as developed' because it has received NO feedback.

@tnovotny
Copy link
Author

this one breaks c++98 compatibility btw

@timblechmann I don't think that's an argument. Move-able and move-only types added after c++98 really broke lock_free as it does not support them and its been 6 years.

@timblechmann
Copy link
Collaborator

@tnovotny some projects are bound to older compilers for various reasons. new boost libraries may choose not to support them, but older libraries should not fail to compile after a library update. if new functionality is added, it will have to be guarded by the corresponding config macros.

if you're improving the PR to make it compatible with c++98 (i'm fine with just not supporting movable types rather than using boost's move emulation), i'm more than happy to merge this PR and close the other one.

@tnovotny
Copy link
Author

@timblechmann I'm not a versed boost-developer, so a quick question. Should I use the BOOST_NO_CXX11_RVALUE_REFERENCES macro for this or is there a better alternative?

@timblechmann
Copy link
Collaborator

@tnovotny yes BOOST_NO_CXX11_RVALUE_REFERENCES is probably the way to go. also for type traits, it would be safest to use the boost versions (or introduce a compatibility layer as i've done for the atomic data structures)

@tnovotny
Copy link
Author

tnovotny commented Dec 30, 2017

Since this one was closed I added an updated PR as version as #41.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants