«

peter koch wrote:
> qazmlp1...@rediffmail.com 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.

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:

>> test* testPtr = new test() ;
>>
>> vecTest.push_back( testPtr ) ;
>>

Object deleted here, exactly once.

>> delete testPtr ;
>>
>> vecTest.clear() ;
>> }
>


--

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

Pete Becker wrote:
> Clark S. Cox III wrote:
> > Stuart Redmann wrote:
> > > 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).
> >
>
> 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).

--
Clark S. Cox III

<> wrote in message
news: ups.com...
> 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.

Clark S. Cox III wrote:
> Pete Becker wrote:
>> Clark S. Cox III wrote:
>>> Stuart Redmann wrote:
>>>> 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).
>>>
>> 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).
>

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)

Pete Becker skrev:
> peter koch wrote:
> > qazmlp1...@rediffmail.com 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.
>
> 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

peter koch wrote:
> Pete Becker skrev:
>> peter koch wrote:
>>> qazmlp1...@rediffmail.com 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.
>> 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)

Pete Becker wrote:
>
> 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 ; }

"" 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() ;"

Grizlyk wrote:
> Pete Becker wrote:
>> 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 ; }
>
> "" 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)