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
HLSL++ structs do not support move-semantics #40
Comments
Hi @egorodet I think in theory you're right, although in practice I'm seeing the compiler is allowing std::move to happen on a vector with no issues both using LLVM and MSVC. Have you found otherwise in practice? I actually am going to agree nonetheless that it's simpler to just remove the copy constructors everywhere and let the compiler do its thing which its going to do correctly anyway, as you say the standard is clear about move constructors in the presence of a user-provided copy constructor. |
As an aside, I have found through investigating some inconsistencies in the empty constructor, where for some structures I zero-initialize but for some I don't. I'm going to fix them all as well as part of that commit. |
Closed via 0a78236 |
According to C++ standard |
In the last commit I've noticed that |
Yeah I understand what you're saying wrt std::move. The piece of code I was trying out was std::vector<float4x4> myVector;
myVector.push_back(float4x4());
std::vector<float4x4> myVector2;
myVector2 = std::move(myVector); Looking at myVector, the move had correctly succeeded as it was now invalid and all the content belonged to myVector2, so I think shows it was allowing the move even though by the letter it shouldn't have. |
Your example does not desribe the case with missing move constructor because you're moving the |
I think I need to read up on move semantics more as I think I don't quite understand all the different subtleties involved. In your original message you were saying
so I thought that float4x4 not having a move constructor would somehow inhibit std::vector's move operation, which is why I was doing the test. I suppose now you're talking about moving the float4x4 itself, or creating a structure on top that attempts to move it. In terms of whether it's a compiler failure or not, it would be easy to check the disassembly to see what the compiler is doing and determine whether move is happening or not. Regardless, I think the solution you proposed and has gone in already is the correct one. |
|
User-defined copy constructor still exists for hlslpp_inline float4x4(const float4x4& m) |
HLSL++ vector and matric structs have user-defined copy constructor which breaks "rule of zero", but do not define copy assignment, move constructor and move assignment operators which also means that these types also do not follow "rule of five" resulting in missing support of move semantics and lower performance when used in STL containers like
std::vector
.It seems like HLSL++ types do not need to have user-defined copy constructor. Removing of user-defined copy-constructors will let the compiler generate correct implementations of noexcept copy/move constructors and noexcept assignment operators unlocking the effective memory management in modern C++.
The text was updated successfully, but these errors were encountered: