Re: Can a temporary be assigned to itself?
On 3/23/2013 12:24 PM, ?? Tiib wrote:
I have had bad experience with assignment
damaging things. Since '=' is so innocent in code I feel it should be
I can understand that. In the early days I also had many problems
related to op=. Then we learned the rule of three. Then we learned RAII,
and sticking to that resulted elimination of hand-crafted op= and cctor
from user code. From there I recall no problems worth mentioning.
If I see an op= in code, my first reaction is to ask a ton of questions
why is it there, and likely result is to send the whole class to design
table. For good. :) In fewer cases it is just cut with slight
modifications. In the remaining rare cases it gets a very thorough
review considering all kind of scenarions, including self-assignment and
exceptions at any point.
I have a full suite of smart pointers: NC, DC, transfer and shared,
certainly if I want a copyable object I use a the DC variant over
Reference or constant members you avoid?
I'm not avoiding them, but they're pretty rare turn turn up. And I can't
recall a single case they would trigger special ops -- the natural
consequence is a sensible default cctor and a deleted op=, that is fine
for me. If I wrote them by hand the copy would not be "equivalent" to
the original, and I guess that would surprise someone later on.
shared_ptr member is quite common.
Not in my work. But I see no problem with it -- if it's used for
sharing, then it will apply for its container just by doing nothing. (Or
the container deletes the copy possibility and just uses it as a NC
holder for other conveniences -- my NC pointer uses CHECKED_DELETE,
shared_ptr is smarter than that.)
Sometimes deep copy sometimes shared copy is needed
when copying an object with such member.
IMO it's rarther either shared or NC. If I want DC, why pick the
shared_ptr over DC in the first place?
Your DC pointer is
interesting. Does it have non-owning side-kick or do you use raw pointer
instead? Transfer and non-copyable ... isn't it unique_ptr?
'Transfer' is the plain old auto_ptr, replaced by unique_ptr these days.
NC would have been boost::scoped_ptr, but it turned out to have crippled
interface, so I made mine using auto_ptr's interface (I like the
reset/release a lot, and need get regularly dealing with C-interfaced
other components), just stripped cctor, op=, the templated ctors (mostly
out of fear) and the deleter comes from policy. In some environments it
got an extra member to allow external init (do reset() and provide &ptr
to be assigned) where such approach to create new objects is common.
IMO same applies to any resource handler. (btw the said
pointers are policy-based so it's easy to use them for any kind of
resource; I recall a few times using fake-copy that was okay for the
I avoid allowing assignment or copying of resources like threads, files or
sockets with just '=' character ... being laconic here is hiding the cost
tag that certainly matters. Moving is better since it is cheaper.
I used all of those only for NC. Certainly move would make sense, but
the compilers I use did not yet pick up move semantics properly,
eventually I'll switch to more of that.
IME starting to hand-craft an op= is the last resort and is a ticked for
more easy-to-break maintenance too.
It is important to make novice to realize that compiler will create the
things itself if it only can and that compiler does not always
understand his intentions.
Rule of 3 covers that, and certainly a novice shall never gain check-in
rights before mastering that (along with rest of EC++3rd)...
If novice does not know that issue with
classes in C++ then he is doomed to write broken classes. Everybody
have seen copyable singletons I trust? Hiding that part of C++ does
not work it feels.
.... but knowing those details do not map directly to design and coding,
there's way more. And broken classes are supposed to be caught on
review. sure, novices are doomed to write a ton of them before gaining
wisdom to get it right on the first attempt. and with strict meaning of
'broken' I guess even veterans fail with the first attempt more often
than not. ;-)))
IRL we fight program complexity on a broader level, that usually imposes
restrictions on how objects are created, held, disposed of; implicit
responsibilities for some actions, forbidding some other activity (like
storing pointers/refs to a thing you can't prove to live long enough).
Note that implicit assignment operators do not even offer the
basic exception safety guarantee on lot of cases.
They do memberwise assignment, that I recall was fine for all my value
classes. I try to imagine a broken situation, but the only scenario
jumps to mind is when I have a group of members that shall be in synch
and one may throw on copy -- my first question would be "how come that
group is not a class in its own right?"
So either everything
is nothrow during assignment or you *have* to hand-craft them.
IMO we're lightyears from that.