c++ - Why user-defined move-constructor disables the implicit copy-constructor? -
while i'm reading boost/shared_ptr.hpp, saw code:
// generated copy constructor, destructor fine... #if defined( boost_has_rvalue_refs ) // ... except in c++0x, move disables implicit copy shared_ptr( shared_ptr const & r ): px( r.px ), pn( r.pn ) // never throws { } #endif
what comment "generated copy constructor, destructor fine except in c++11, move disables implicit copy" mean here? shall write copy ctor ourselves prevent situation in c++11?
i've upvoted ildjarn's answer because found both accurate , humorous. :-)
i'm providing alternate answer because i'm assuming because of title of question op might want know why standard says so.
background
c++ has implicitly generated copy members because if didn't, would've been still-born in 1985 because so incompatible c. , in case wouldn't having conversation today because c++ wouldn't exist.
that being said, implicitly generated copy members akin "deal devil". c++ couldn't have been born without them. evil in silently generate incorrect code in significant number of instances. c++ committee isn't stupid, know this.
c++11
now c++ has been born, , has evolved successful grownup, committee love say: we're not doing implicitly generated copy members more. dangerous. if want implicitly generated copy member have opt-in decision (as opposed opt-out of it). considering amount of existing c++ code break if done, tantamount suicide. there huge backwards compatibility concern quite justified.
so committee reached compromise position: if declare move members (which legacy c++ code can't do), we're going assume default copy members wrong thing. opt-in (with =default
) if want them. or write them yourself. otherwise implicitly deleted. our experience to-date in world move-only types indicates default position quite commonly desired (e.g. unique_ptr
, ofstream
, future
, etc.). , expense of opting-in quite small = default
.
looking forward
the committee love say: if you've written destructor, implicit copy members incorrect, delete them. c++98/03 "rule of three". break lots of code. committee has said in c++11 if provide user-declared destructor, implicit generation of copy members is deprecated. means feature removed in future standard. , day compiler might start issuing "deprecated warnings" in situation (the standard can not specify warnings).
conclusion
so forewarned: c++ has grown , matured on decades. , means father's c++ may need migrating deal child's c++. slow, gradual process don't throw hands , port language. is change, if slow.
Comments
Post a Comment