Using-declaration of assignment operators results in incorrect return type #372
Assignees
Labels
Comments
Lastique
added a commit
to Lastique/tbb
that referenced
this issue
Apr 4, 2021
This fixes incorrect return types of assignment operators imported from base classes. Other than copy and move assignment operators, which are generated by the compiler even if imported with a using-declaration, the imported operators will be returning a reference to the base class instead of the derived class. In concurrent_queue, the assignment operator was missing while copy/move constructors were present and contained non-trivial logic. The implicitly generated assignment operator would have been incorrect. The added assignment operator reuses copy/move constructors to implement assignment. In concurrent_bounded_queue, the assignment operator was also missing and would have been deleted because of std::atomic member, while the class also had copy and move constructors. The added assignment operator also reuses the existing constructors. Fixes oneapi-src#372. Fixes oneapi-src#373.
|
@kboyarinov, can you please look at the issue? |
|
It seems that only the following containers are affected :
While specification for them is correct, implementation is not. Conformance testing does not test for this as well. |
|
You forgot |
Lastique
added a commit
to Lastique/tbb
that referenced
this issue
Nov 25, 2021
This fixes incorrect return types of assignment operators imported from base classes. Other than copy and move assignment operators, which are generated by the compiler even if imported with a using-declaration, the imported operators will be returning a reference to the base class instead of the derived class. In concurrent_queue, the assignment operator was missing while copy/move constructors were present and contained non-trivial logic. The implicitly generated assignment operator would have been incorrect. The added assignment operator reuses copy/move constructors to implement assignment. In concurrent_bounded_queue, the assignment operator was also missing and would have been deleted because of std::atomic member, while the class also had copy and move constructors. The added assignment operator also reuses the existing constructors. Fixes oneapi-src#312. Fixes oneapi-src#372. Fixes oneapi-src#373.
Lastique
added a commit
to Lastique/tbb
that referenced
this issue
Nov 25, 2021
This fixes incorrect return types of assignment operators imported from base classes. Other than copy and move assignment operators, which are generated by the compiler even if imported with a using-declaration, the imported operators will be returning a reference to the base class instead of the derived class. In concurrent_queue, the assignment operator was missing while copy/move constructors were present and contained non-trivial logic. The implicitly generated assignment operator would have been incorrect. The added assignment operator reuses copy/move constructors to implement assignment. In concurrent_bounded_queue, the assignment operator was also missing and would have been deleted because of std::atomic member, while the class also had copy and move constructors. The added assignment operator also reuses the existing constructors. Fixes oneapi-src#312. Fixes oneapi-src#372. Fixes oneapi-src#373. Signed-off-by: Andrey Semashev <[email protected]>
Lastique
added a commit
to Lastique/tbb
that referenced
this issue
Dec 1, 2021
…ntainers. This fixes incorrect return types of assignment operators imported from base classes. Other than copy and move assignment operators, which are generated by the compiler even if imported with a using-declaration, the imported operators will be returning a reference to the base class instead of the derived class. Fixes oneapi-src#372. Signed-off-by: Andrey Semashev <[email protected]>
isaevil
pushed a commit
that referenced
this issue
Dec 2, 2021
…ntainers. This fixes incorrect return types of assignment operators imported from base classes. Other than copy and move assignment operators, which are generated by the compiler even if imported with a using-declaration, the imported operators will be returning a reference to the base class instead of the derived class. Fixes #372. Signed-off-by: Andrey Semashev <[email protected]>
14 tasks
anton-potapov
pushed a commit
that referenced
this issue
Dec 2, 2021
* Fixed incorrect definitions of assignment operators in associative containers. This fixes incorrect return types of assignment operators imported from base classes. Other than copy and move assignment operators, which are generated by the compiler even if imported with a using-declaration, the imported operators will be returning a reference to the base class instead of the derived class. Fixes #372. Signed-off-by: Andrey Semashev <[email protected]> Signed-off-by: Ilya Isaev <[email protected]>
kboyarinov
pushed a commit
that referenced
this issue
Dec 27, 2021
* Fixed incorrect definitions of assignment operators in associative containers. This fixes incorrect return types of assignment operators imported from base classes. Other than copy and move assignment operators, which are generated by the compiler even if imported with a using-declaration, the imported operators will be returning a reference to the base class instead of the derived class. Fixes #372. Signed-off-by: Andrey Semashev <[email protected]> Signed-off-by: Ilya Isaev <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There are a number of instances in oneTBB where the code imports
operator=from a base class with ausing-declaration. This is incorrect because the importedoperator=that are not copy or move assignment operators will have the return type of a reference to the base class instead of the derived class. (For copy and move assignment operators the standard makes an exception, as in this case it forces the implicit generation of the assignment operators in the derived class instead of importing the operators from the base class, see [class.copy.assign]/8.) Here is a demonstration.The solution is to define
operator=in the derived classes explicitly for all argument types, and forward to the base classoperator=. #318 implements this for concurrent containers.The text was updated successfully, but these errors were encountered: