Closed danmou closed 2 months ago
Your change is definitely correct. I think the reason it wasn't caught is that nothing uses LockedPtr<T>::operator=
so it just isn't built in the code-base as-is (AKA not covered by tests). Probably your new version of gcc catches this anyway (or you were using that operator=
assignment so it tried and failed to build it). I'm using 13.2.0, which doesn't catch this.
Thank you for the change! I'm going to add a usage of the LockedPtr to an example and will have a PR with that shortly.
I created #24 to address the lack of tests for this. It still doesn't test the move constructor, but I'm not sure of the use case of that anyway. To test your branch, I added a usage of the move constructor for locked pointer, but it was a contrived usage just to get it to build that function. Do you have a better usage example? If so, it would be great if you could comment it on #24 or just create a separate PR with an example or test utilizing it.
Thanks, that makes sense! I'm new to this library so I'm not aware of a use case for that move constructor (but presumably no one has used it so far, or they would have encountered the bug).
With master I get the following compile error (using CMake 3.30.2 and GCC 14.2.1 on Linux):
It seems the issue was introduced in #18. I'm a bit confused how it wasn't discovered in all this time, doesn't seem like it should be compiler-dependent? Anyway the fix was simple.