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

Popular posts from this blog

c# - SVN Error : "svnadmin: E205000: Too many arguments" -

c# - Copy ObservableCollection to another ObservableCollection -

All overlapping substrings matching a java regex -