aaron.ballman added inline comments.
================
Comment at: test/clang-tidy/misc-move-const-arg.cpp:75-76
@@ +74,4 @@
+
+class NonMoveable {
+ public:
+ NonMoveable();
----------------
> Can you expand on this?
>
> The standard says: "If the definition of a class X does not explicitly
> declare a move constructor, one will be implicitly declared as defaulted if
> and only if - X does not have a user-declared copy constructor [...]"
> (12.8/9).
>
> Because I'm declaring a copy constructor, I would thus have expected not to
> get an implicitly-declared move constructor. Where am I going wrong here?
Move operations are optimized versions of a copy operation, so a failed move
operation can fall back to perform a copy operation instead and achieve the
same operational semantics but with slightly worse performance. Because you
have a copy constructor, you do not get an implicitly-declared move constructor
(so that's correct), but that doesn't mean the type cannot be used in a context
where the user expects a move (i.e., calling `std::move()` on it) -- the
operation just falls back on the copy constructor.
Basically, there's an operational difference between not having the
implicitly-declared move constructor and having a deleted move constructor. In
the former, fallback to copy happens and in the latter you get a diagnostic. So
when I hear "non-moveable type", my brain assumes you mean "get a diagnostic
when you try to move."
http://reviews.llvm.org/D21223
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
