Necessary for copy constructor??

[qazmlp1209]

Will the following program cause any problem, because of the missing
explicit copy constructor for the 'test' class?

#include <vector>
#include <iostream>

class test
{
char* cPtr ;

public:

test()
{
cPtr = new char[10] ;
}

~test()
{
delete cPtr ;
}
} ;


int main()
{
std::vector< test*> vecTest ;

test* testPtr = new test() ;

vecTest.push_back( testPtr ) ;

delete testPtr ;

vecTest.clear() ;
}

 

[Stuart Redmann]

Will the following program cause any problem, because of the missing
explicit copy constructor for the 'test' class?

#include <vector>
#include <iostream>

class test
{
char* cPtr ;

public:

test()
{
cPtr = new char[10] ;
}

~test()
{
delete cPtr ;
}
} ;


int main()
{
std::vector< test*> vecTest ;

test* testPtr = new test() ;

vecTest.push_back( testPtr ) ;

delete testPtr ;

vecTest.clear() ;
}

Nope. As pointers have their own copy constructor, you can use them in
STL containers freely.

Regards,
Stuart

 

[peter koch]

(e-mail address removed) skrev:

Will the following program cause any problem, because of the missing
explicit copy constructor for the 'test' class?

Yes. You will have double deletes. Depending on your real needs, you
should use std::vector or std::string instead of the lowlevel pointer.
In fact, operator new[] should almost never be used. Prefer std::vector
(or in rare situations raw operator new)

/Peter

#include <vector>
#include <iostream>

class test
{
char* cPtr ;

public:

test()
{
cPtr = new char[10] ;
}

~test()
{
delete cPtr ;
}
} ;


int main()
{
std::vector< test*> vecTest ;

test* testPtr = new test() ;

vecTest.push_back( testPtr ) ;

delete testPtr ;

vecTest.clear() ;
}

 

[qazmlp1209]

(e-mail address removed) skrev:

Yes. You will have double deletes.

You are right, in general (Every class having a pointer member should
have an explicit constructor defined correctly).
But, could you comment whether it will cause problem for the code that
I have given within main()?

Depending on your real needs, you
should use std::vector or std::string instead of the lowlevel pointer.
In fact, operator new[] should almost never be used. Prefer std::vector
(or in rare situations raw operator new)

 

[dasjotre]

Will the following program cause any problem, because of the missing
explicit copy constructor for the 'test' class?

I don't think that the copy constructor is generated in this case
since it is not used.

But, could you comment whether it will cause problem for the code that
I have given within main()?

since only the pointer is copied and not the object it poins to the
answer is no.

( delete cPtr should be delete [] cPtr )

 

[peter koch]

(e-mail address removed) skrev:

You are right, in general (Every class having a pointer member should
have an explicit constructor defined correctly).
But, could you comment whether it will cause problem for the code that
I have given within main()?

It is not. But this is no excuse for disabling copy-construction (and
assignment).

/Peter

 

[Clark S. Cox III]

Will the following program cause any problem, because of the missing
explicit copy constructor for the 'test' class?

#include <vector>
#include <iostream>

class test
{
char* cPtr ;

public:

test()
{
cPtr = new char[10] ;
}

~test()
{
delete cPtr ;
}
} ;


int main()
{
std::vector< test*> vecTest ;

test* testPtr = new test() ;

vecTest.push_back( testPtr ) ;

delete testPtr ;

vecTest.clear() ;
}

Nope. As pointers have their own copy constructor, you can use them in
STL containers freely.

Woah there! That's horrible advice. Without a copy constructor, using
such an object in an STL container will invariably lead to
double-deletes (i.e. undefined behavior).

Remember the rule of three: Generally, if a class requires any of the
following three to be implemented then it requires that *all* of the
three be implemented:

destructor
assignment operator
copy constructor

 

[Clark S. Cox III]

I don't think that the copy constructor is generated in this case
since it is not used.

Conceptually, the copy constructor is always generated unless you
provide one. Whether that has an impact on the final output of the
compiler when it isn't called is platform dependent.

But, could you comment whether it will cause problem for the code that
I have given within main()?

since only the pointer is copied and not the object it poins to the
answer is no.

( delete cPtr should be delete [] cPtr )

 

[Eberhard Schefold]

Woah there! That's horrible advice. Without a copy constructor, using
such an object in an STL container will invariably lead to
double-deletes (i.e. undefined behavior).

The point is here that not the object is used in the container. A
pointer to the object is. The example as shown has no problems (apart
from the "delete" instead of "delete[]"). Even if the object is not
copy-able, you can still use pointers in a container.

What I would do is to make the class explicitly non-copyable and
non-assignable, so the compiler can report any misuse.

 

[Pete Becker]

Woah there! That's horrible advice. Without a copy constructor, using
such an object in an STL container will invariably lead to
double-deletes (i.e. undefined behavior).

Whoa, again! In the specific context of the original example, there is
no problem with double deletes. Pointers do, in fact, have valid copy
semantics. There is, as you suggest, a possible issue of keeping track
of ownership, but there's nothing wrong with the original code. It
correctly deletes the one object that it creates.

If you want a container to also manage lifetimes, then you've got a
significant design problem: you also have to make sure that every other
piece of code is clear on ownership. But there are situations where it's
appropriate for a container to manage pointers but not worry about
lifetimes, such as maintaining a list of currently active objects from a
set of statically allocated ones.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

 

[Pete Becker]

(e-mail address removed) skrev:

Yes. You will have double deletes.

No, there are no double deletes in the posted code.

Depending on your real needs, you
should use std::vector or std::string instead of the lowlevel pointer.
In fact, operator new[] should almost never be used. Prefer std::vector
(or in rare situations raw operator new)

/Peter

#include <vector>
#include <iostream>

class test
{
char* cPtr ;

public:

test()
{
cPtr = new char[10] ;
}

~test()
{
delete cPtr ;
}
} ;


int main()
{
std::vector< test*> vecTest ;

Object allocated here, never copied:

Object deleted here, exactly once.


--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

 

[Clark S. Cox III]

Whoa, again! In the specific context of the original example, there is
no problem with double deletes. Pointers do, in fact, have valid copy
semantics.

Indeed, I see that now (i.e. that the OP was creating a vector of
*pointers* to test).

 

[Jim Langston]

Will the following program cause any problem, because of the missing
explicit copy constructor for the 'test' class?

#include <vector>
#include <iostream>

class test
{
char* cPtr ;

public:

test()
{
cPtr = new char[10] ;
}

~test()
{
delete cPtr ;
}
} ;


int main()
{
std::vector< test*> vecTest ;

test* testPtr = new test() ;

vecTest.push_back( testPtr ) ;

delete testPtr ;

vecTest.clear() ;
}

As used, there won't be a problem. But, you should either make a non public
copy and assignment operator, or make them. The reason is if you do try to
copy this class you'll get a double delete. Making a non public copy and
assignement operator means you can't accidently copy the class.

 

[Pete Becker]

Indeed, I see that now (i.e. that the OP was creating a vector of
*pointers* to test).

Yup. Looking at how to use non-copyable objects in containers, I suspect.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

 

[peter koch]

Pete Becker skrev:

No, there are no double deletes in the posted code.

[snip]

You are right - I only skimmed "main" and failed to notice that it was
a vector of pointers. Still, there's no excuse for not hiding operator=
and the copy constructor.

/Peter

 

[Pete Becker]

Pete Becker skrev:

No, there are no double deletes in the posted code.

[snip]

You are right - I only skimmed "main" and failed to notice that it was
a vector of pointers. Still, there's no excuse for not hiding operator=
and the copy constructor.

Sure there is: it's an experiment, not production code.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

 

[Grizlyk]

Yup. Looking at how to use non-copyable objects in containers, I suspect.

But dangerous usage

test() { cPtr = new char[10] ; }

test():cPtr(new char[10]) { }

~test(){ delete cPtr ; }

~test(){ delete[] cPtr ; }

"(e-mail address removed)" must at least define private copy&assign
private:
test(const test&):cPtr(0) { abort(); }
void operator= (const test&){ abort(); }

and he does not call "delete testPtr;" befor "vecTest.clear() ;"

 

[Pete Becker]

Yup. Looking at how to use non-copyable objects in containers, I suspect.

But dangerous usage

test() { cPtr = new char[10] ; }

test():cPtr(new char[10]) { }

~test(){ delete cPtr ; }

~test(){ delete[] cPtr ; }

"(e-mail address removed)" must at least define private copy&assign
private:
test(const test&):cPtr(0) { abort(); }
void operator= (const test&){ abort(); }

and he does not call "delete testPtr;" befor "vecTest.clear() ;"

No, there's nothing dangerous in the code as written. But I'm sure he's
grateful for all the advice about how code that's supposed to do
something different should be written.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)