copy constructor for class with member pointer
in [C++]
|
Prev: compilation error when Base Constructor calling pure virtual method
Next: will taking the address of the first element of a string break COW strings?
From: Sergey Lukoshkin on 10 Jul 2010 23:28 Hello, everyone! I faced such a problem. Say I got the class: class foo { public: foo(); ~foo(); private: T* m_ptr; }; I need to implement copy constructor. So, the common signature for it is foo( const& other ). I have to take the pointer from another object, assign it to this->m_ptr and then make other.m_ptr = 0. But such a solution discards constness of the other object and signature of copy constructor should be foo( foo& other ). Is the approach a correct way to implement the copy constructor for class with member pointer or not? Loosing constness of argument makes me hesitating. Thanks. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Bo Persson on 11 Jul 2010 04:46 Sergey Lukoshkin wrote: > Hello, everyone! > > I faced such a problem. Say I got the class: > > class foo > { > public: > foo(); > ~foo(); > > private: > > T* m_ptr; > }; > > I need to implement copy constructor. So, the common signature for > it is foo( const& other ). I have to take the pointer from another > object, assign it to this->m_ptr and then make other.m_ptr = 0. But > such a solution discards constness of the other object and signature > of copy constructor should be foo( foo& other ). > > Is the approach a correct way to implement the copy constructor for > class with member pointer or not? Loosing constness of argument > makes me hesitating. Thanks. It depends on what the semantics of your is supposed to be. Should the T object be shared among the foos, or should they have one each? The most common way is to make a copy of the T, and have the m_ptr point to its own copy. That's what std::vector and std::string do. On the other hand, std::auto_ptr is an example of where the new copy owns the T, and the original auto_ptr gives it up. Bo Persson -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Jerry Stuckle on 11 Jul 2010 04:43 Sergey Lukoshkin wrote: > Hello, everyone! > I faced such a problem. Say I got the class: > class foo > { > public: > foo(); > ~foo(); > private: > T* m_ptr; > }; > I need to implement copy constructor. So, the common signature for it > is foo( const& other ). I have to take the pointer from another > object, assign it to this->m_ptr and then make other.m_ptr = 0. But > such a solution discards constness of the other object and signature > of copy constructor should be foo( foo& other ). > Is the approach a correct way to implement the copy constructor for > class with member pointer or not? Loosing constness of argument makes > me hesitating. Thanks. No, generally you make a copy of the object pointed, and set the new object's pointer in this m_ptr. You do NOT want to change the pointer in the other object. That's why it is const! -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex(a)attglobal.net ================== [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: terminator on 11 Jul 2010 04:50 On Jul 11, 6:28 pm, Sergey Lukoshkin <sergey....(a)gmail.com> wrote: > Hello, everyone! > > I faced such a problem. Say I got the class: > > class foo > { > public: > foo(); > ~foo(); > > private: > > T* m_ptr; > > }; > > I need to implement copy constructor. So, the common signature for it > is foo( const& other ). I have to take the pointer from another > object, assign it to this->m_ptr and then make other.m_ptr = 0. But > such a solution discards constness of the other object and signature > of copy constructor should be foo( foo& other ). > > Is the approach a correct way to implement the copy constructor for > class with member pointer or not? Loosing constness of argument makes > me hesitating. Thanks. I do not exactly see what u wanna do but schema described above will definitely lead to crash. The usual process is: 1- to construct the ptr with new/allocator 2- destruct with delete/deallocator struct foo{ foo(){ptr=new bar;}; foo(foo const & x){ptr=new bar(*x.ptr);}; ~foo(){delete ptr;}; private: bar* ptr; }; but if u need a move-constructor then u gotta read a lot of stuff. regards, FM. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Daniel Krügler on 11 Jul 2010 04:53
On 11 Jul., 16:28, Sergey Lukoshkin <sergey....(a)gmail.com> wrote: > I faced such a problem. Say I got the class: > > class foo > { > public: > foo(); > ~foo(); > > private: > > T* m_ptr; > > }; > > I need to implement copy constructor. So, the common signature for it > is foo( const& other ). I have to take the pointer from another > object, assign it to this->m_ptr and then make other.m_ptr = 0. But > such a solution discards constness of the other object and signature > of copy constructor should be foo( foo& other ). > > Is the approach a correct way to implement the copy constructor for > class with member pointer or not? Loosing constness of argument makes > me hesitating. Thanks. It depends: In general a copy-constructor with reference arguments to const should not mutate it's source argument in an *observable* way. You didn't say whether your member of type pointer is an implementation detail or not. If it is an implementation detail, your type should work in contexts where the compiler omits to call the copy- constructor (because the language explicitly provides freedom to implementations to do so, even, if such an omission would have observable effects (e.g. if the copy- constructor outputs to std::cout). If it is not an implementation detail, you should declare the copy-constructor as one that takes a reference to non-const - this is basically the route, std::auto_ptr decided for. Note that such a decision will have the effect that you cannot copy from rvalues. If the latter use-case is important to you and if you have a C++0x-cappable compiler with support for rvalue, references, the best decision would probably be to design your type foo as follows: class foo { public: foo(foo&& rhs) : m_ptr(rhs.m_ptr) { rhs.m_ptr = 0; } foo& operator=(foo&& rhs) { m_ptr = rhs.m_ptr; rhs.m_ptr = 0; return *this; } private: T* m_ptr; }; [With the provision of user-declared move operations as below, the compiler won't provide the default versions of the copy operations. If you prefer that to be more explicit, you could also declare the copy operations as deleted member functions] HTH & Greetings from Bremen, Daniel Kr�gler -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |