non-const constructor

[Dieter Stueken]

A class containing a pointer to a dynamically allocated object should
have a well defined copy constructor and assignment operator or declare
them private to avoid an unintentional copy of the pointer.

But what happens in case of a non-const copy constructor?
Often a deep copy is unwanted or even impossible. But often it
may make sense, to transfer the pointer (or any other class data)
to an other instance of that class, leaving an empty class.
This is very similar to what std::auto_ptr is doing. I think
this might be a very good and efficient approach for returning
a class by value:

#include <algorithm>

class C
{
private:
char* m_p; // some internal data

void swap(C& c) // swap internal data with other class
{std::swap(m_p, c.m_p);}

public:
C(size_t n=0) // some constructor
: m_p(n?new char[n]:0)
{};

~C() // destructor
{ if(m_p) delete m_p; }

C(C& c) : m_p(0) // the non const copy constructor
{swap(c);}

private:
C& operator= (const C&); // no assign, but might be defined similar
};

// return C by value

C create(size_t n)
{
C c(n);
return c; // return without making a deep copy
}

// some examples

int main()
{
C a (create(7));
C b(a); // a should be left empty ba now

return 0;
}

Q: is this good style or just a hack?
Do I still have to define a private C(const C&) to be save?
My GCC 2.95.2.1 won't compile with an error:

initialization of non-const reference type `class C &'
from rvalue of type `C'
in passing argument 1 of `C::C(C &)'

If I define a public: C(const C&); my GCC compiles, but
the declared const copy constructor is never used.
Thus I think this is a compiler bug.

If I have both a const and a non-const copy constructor,
would create() use the (more efficient) non-const copy
automatically?

Ditz.
--
Dieter Stüken, con terra GmbH, Münster
stu...@conterra.de stu...@qgp.uni-muenster.de
http://www.conterra.de/ http://qgp.uni-muenster.de/~stueken
(0)251-980-2027 (0)251-83-334974

[Ron Natalie]

>
> Q: is this good style or just a hack?
> Do I still have to define a private C(const C&) to be save?
> My GCC 2.95.2.1 won't compile with an error:
>
> initialization of non-const reference type `class C &'
> from rvalue of type `C'
> in passing argument 1 of `C::C(C &)'
>
> If I define a public: C(const C&); my GCC compiles, but
> the declared const copy constructor is never used.
> Thus I think this is a compiler bug.
>
> If I have both a const and a non-const copy constructor,
> would create() use the (more efficient) non-const copy
> automatically?

You've already deduced the impact of a non-const copy constructor.
Object copying will fail if the source is const (or is an temporary).

If you defined the const copy constructor, it should be used.

What is happening however, is removal of a temporary copy, I believe.
The rules say that you still need to have an accessible copy constructor
(which you didn't when it was non-const), but it can optimize out the
creation of the intermediate object provided there was no different
other than the ommission of the call of the constructor/destructor
for the omitted temporary.

[Sai Shankar]

Dieter Stueken wrote:
>
> A class containing a pointer to a dynamically allocated object should
> have a well defined copy constructor and assignment operator or declare
> them private to avoid an unintentional copy of the pointer.
>
> But what happens in case of a non-const copy constructor?
> Often a deep copy is unwanted or even impossible. But often it
> may make sense, to transfer the pointer (or any other class data)
> to an other instance of that class, leaving an empty class.

You might want to look into reference counting the class data.
Look at the shared_ptr from Boost (http://www.boost.org) for more
details.

Regards
Sai

[Sai Shankar]

Sai Shankar wrote:
>
> Dieter Stueken wrote:
> >
> > A class containing a pointer to a dynamically allocated object should
> > have a well defined copy constructor and assignment operator or declare
> > them private to avoid an unintentional copy of the pointer.
> >
> > But what happens in case of a non-const copy constructor?
> > Often a deep copy is unwanted or even impossible. But often it
> > may make sense, to transfer the pointer (or any other class data)
> > to an other instance of that class, leaving an empty class.

I forgot to mention that doing such a thing makes your class unusable with
standard containers.

Regards
Sai