Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #2996 > unrolled thread

Destructors can copying objects

Back to article view | Back to comp.lang.c++

Contents

  Destructors can copying objects Ruben Safir <ruben@mrbrklyn.com> - 2011-04-02 12:58 +0000
    Re: Destructors can copying objects Volker Lukas <vlukas@gmx.de> - 2011-04-02 15:29 +0200
      Re: Destructors can copying objects Ruben Safir <ruben@mrbrklyn.com> - 2011-04-03 02:59 +0000
        Re: Destructors can copying objects "Balog Pal" <pasa@lib.hu> - 2011-04-03 11:32 +0200
          Re: Destructors can copying objects Leigh Johnston <leigh@i42.co.uk> - 2011-04-03 12:29 +0100
            Re: Destructors can copying objects Bart van Ingen Schenau <bart@ingen.ddns.info> - 2011-04-04 13:43 +0200
              Re: Destructors can copying objects Michael Doubez <michael.doubez@free.fr> - 2011-04-05 01:26 -0700
            Re: Destructors can copying objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-04-04 14:03 -0700
              Re: Destructors can copying objects Ruben Safir <ruben@mrbrklyn.com> - 2011-04-04 21:10 +0000
              Re: Destructors can copying objects Leigh Johnston <leigh@i42.co.uk> - 2011-04-04 22:28 +0100
            Re: Destructors can copying objects Ruben Safir <ruben@mrbrklyn.com> - 2011-04-04 21:07 +0000
              Re: Destructors can copying objects Leigh Johnston <leigh@i42.co.uk> - 2011-04-04 22:31 +0100
                Re: Destructors can copying objects Leigh Johnston <leigh@i42.co.uk> - 2011-04-04 22:43 +0100
                Re: Destructors can copying objects Ruben Safir <ruben@mrbrklyn.com> - 2011-04-04 22:38 +0000
                  Re: Destructors can copying objects Leigh Johnston <leigh@i42.co.uk> - 2011-04-04 23:42 +0100
                  Re: Destructors can copying objects Ruben Safir <ruben@mrbrklyn.com> - 2011-04-04 22:54 +0000
        Re: Destructors can copying objects James Kanze <james.kanze@gmail.com> - 2011-04-03 10:07 -0700
          Re: Destructors can copying objects Ruben Safir <ruben@mrbrklyn.com> - 2011-04-04 21:14 +0000
          Re: Destructors can copying objects Ruben Safir <ruben@mrbrklyn.com> - 2011-04-04 21:17 +0000
            Re: Destructors can copying objects LR <lruss@superlink.net> - 2011-04-05 01:52 -0400
      Re: Destructors can copying objects Ruben Safir <ruben@mrbrklyn.com> - 2011-04-03 03:08 +0000
        Re: Destructors can copying objects Paavo Helde <myfirstname@osa.pri.ee> - 2011-04-03 02:11 -0500
        Re: Destructors can copying objects Volker Lukas <vlukas@gmx.de> - 2011-04-03 12:02 +0200
        Re: Destructors can copying objects Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-03 12:14 +0200
          Re: Destructors can copying objects Roberto Waltman <usenet@rwaltman.com> - 2011-04-03 18:16 -0400
            Re: Destructors can copying objects Ruben Safir <ruben@mrbrklyn.com> - 2011-04-15 23:06 +0000
              Re: Destructors can copying objects LR <lruss@superlink.net> - 2011-04-15 19:19 -0400
          Re: Destructors can copying objects Ruben Safir <ruben@mrbrklyn.com> - 2011-04-15 23:03 +0000
            Re: Destructors can copying objects "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-16 01:47 +0200
              Re: Destructors can copying objects Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-16 13:00 +0200
                Re: Destructors can copying objects "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-16 15:57 +0200
    Re: Destructors can copying objects LR <lruss@superlink.net> - 2011-04-02 09:51 -0400
    Re: Destructors can copying objects Yannick Tremblay <yannick@tremnblay.co.uk> - 2011-04-04 12:56 +0000
      Re: Destructors can copying objects Ruben Safir <ruben@mrbrklyn.com> - 2011-04-04 21:05 +0000
        Re: Destructors can copying objects Paavo Helde <myfirstname@osa.pri.ee> - 2011-04-04 21:56 -0500
        Re: Destructors can copying objects Yannick Tremblay <yannick@tremnblay.co.uk> - 2011-04-05 11:36 +0000
          Re: Destructors can copying objects Ruben Safir <ruben@mrbrklyn.com> - 2011-04-05 15:40 +0000
            Re: Destructors can copying objects Sana <sanatakos@gmail.com> - 2011-04-05 10:11 -0700
            Re: Destructors can copying objects Ruben Safir <ruben@mrbrklyn.com> - 2011-04-05 20:28 +0000
            Re: Destructors can copying objects Yannick Tremblay <yannick@tremnblay.co.uk> - 2011-04-06 11:12 +0000
        Re: Destructors can copying objects drew@furrfu.invalid (Drew Lawson) - 2011-04-05 13:02 +0000
          Re: Destructors can copying objects Ruben Safir <ruben@mrbrklyn.com> - 2011-04-05 15:51 +0000
            Re: Destructors can copying objects drew@furrfu.invalid (Drew Lawson) - 2011-04-05 17:47 +0000
              Re: Destructors can copying objects Ruben Safir <ruben@mrbrklyn.com> - 2011-04-05 20:25 +0000
                Re: Destructors can copying objects drew@furrfu.invalid (Drew Lawson) - 2011-04-05 20:37 +0000

Page 1 of 3  [1] 2 3  Next page →

#2996 — Destructors can copying objects

I am creating a linked link program which created a segmentation fault
and a core at the end of the program. The program is trying to delete an
already deleted object, and I can't seem to protect my program from
this. I fixed the problem by sending an object to a function by
reference rather than by value, but I'm not satisfied with the solution.

The list has node objects

namespace chainlist {


/*
*
=====================================================================================
* Class: Node
* Description: This is a node in the "List" Link List
*
=====================================================================================
*/

template < class unk >
class Node
{
public:

// ==================== LIFECYCLE =======================================
/* constructor */
Node<unk>( unk value, Node<unk> *item_to_link_to = 0);
Node ( const Node &other ); /* copy constructor - Need to write this! */
~Node<unk> (); /* destructor */


/* ==================== ACCESSORS ======================================= */
inline unk* value ()const{
return value_;
}
inline Node<unk> * next()const {
return next_;
}

inline void value(unk *);
inline void value(unk);
inline void next(Node<unk> *);





/* ==================== MUTATORS ======================================= */

/* ==================== OPERATORS ======================================= */


Node& operator=( const Node &other ); // assignment operator
unk& operator*(){ //gain access to real value
return *(value());
}
unk& operator*(unk);

protected:
/* ==================== DATA MEMBERS
======================================= */



private:
/* ==================== DATA MEMBERS
======================================= */

unk * value_ ;
Node * next_;



}; /* ----- end of template class Node ----- */



And they are controlled by a List Object


template < class T >
class List
{
public:

/* ==================== LIFECYCLE ======================================= */
List<T>(): front_(0),end_(0), cursor_(0), size_(0){} /* constructor */
void remove_all();
~List<T>();

/* ==================== ACCESSORS ======================================= */
int size()const { return size_; }
inline Node<T>* const &front()const{ return front_;}
inline Node<T>* &endd(){return end_;}

inline Node<T> *& cursor(){return cursor_;}

inline void cursor(Node<T> * a){ cursor_ = a; }

inline void endd(Node<T> *a){ end_ = a; }
inline void front(Node<T> *a){ front_ = a; }
inline void display();



/* ==================== MUTATORS ======================================= */

inline void sizeup(){ ++size_; }
inline void sizedown(){ --size_; }
void insert_front( T value); //add a node to the front
void insert(T value, Node<T> * &place_after_this); //add a new node
after the Node given and return the new node
void insert(T value); //add a new node at the end of the list
void insert_end(T value); // Add a new node to the end

void find_value(T value); //find a value from it's first occurance in
the list
Node<T>& find_next_value(const T& value, Node<T>& last_node_searched);
//find a value in the list after the
//current node which is not searched
void remove_node_by_value(T value);
void remove_node_by_node(Node<T> cur);
void remove_node_front();
void remove_node_end();



/* ==================== OPERATORS ======================================= */

protected:
/* ==================== DATA MEMBERS
======================================= */

private:
/* ==================== DATA MEMBERS
======================================= */
Node<T> * front_;
Node<T> * end_;
Node<T> * cursor_;
int size_;

}; /* ---------- end of template class Lists ---------- */


The destructors are defined as follows

template<class unk>
Node<unk>::~Node(){
if(value_)
delete value_;
std::cout << "Delete Node" << std::endl;

}

template<class T>
List<T>::~List<T>(){
remove_all();
std::cout << "Deleted All*************" << std::endl;
}



And remove all looks like this
template< class T>
void List<T>::remove_all(){
cursor() = front();
Node<T> * tmp;
while(cursor() != endd()){
tmp = cursor();
cursor() = cursor()->next();
if(tmp)
delete tmp;
}
std::cout << "\n\nReached the End\n\n";
tmp = cursor(); //last node
if(tmp)
delete tmp;
cursor() = 0; //park the cursor
}


I created a large list to test my find functions and passed it by value
to main.
Then passed it by value to a find testing function. when the program ends,
it seems to delete all the nodes from the List twice, once from the local
program and then from main.

Sending it by reference fixed the problem, but I can see other instances
where this can be a huge problem, such as if I decide o delete an
individual node from the list. There has to be a better strategy for
handling this issue.
~

[toc] | [next] | [standalone]

#2997

Ruben Safir wrote: 
> I am creating a linked link program which created a segmentation fault
> and a core at the end of the program. The program is trying to delete
> an already deleted object, and I can't seem to protect my program from
> this. I fixed the problem by sending an object to a function by
> reference rather than by value, but I'm not satisfied with the
> solution.
Why is the member "value_" in your Node template a pointer? Maybe you 
forgot to clone this pointer in Nodes copy constructor. This is just a 
guess. You did not post a full compilable example which represents your 
problem, so it is difficult to find the problem. Please post a full 
program.

Also, there is a list template in the C++ Standard Library. Maybe you 
are coding your own list as an exercise, if not you should consider 
whether using std::list is an option.

[toc] | [prev] | [next] | [standalone]

#3011

On Sat, 02 Apr 2011 15:29:26 +0200, Volker Lukas wrote:

> Ruben Safir wrote:
>> I am creating a linked link program which created a segmentation fault
>> and a core at the end of the program. The program is trying to delete
>> an already deleted object, and I can't seem to protect my program from
>> this. I fixed the problem by sending an object to a function by
>> reference rather than by value, but I'm not satisfied with the
>> solution.
> Why is the member "value_" in your Node template a pointer? 

Because by experience, pointers are easier to set to null which is needed 
from time to time as the end node should be null.

> Maybe you
> forgot to clone this pointer in Nodes copy constructor. 

I don't think I have a copy constructor, which might be the problem 
although it never had been.

The Nodes are separate from the list so when I pass the list by value, I 
created a new list object that when the function stopped, called the list 
destructor, destroying the nodes.  When the program stopped, THEN the 
List destructor was called again and tried to destroy the same node.

At least, that is what I think happened.



> This is just a
> guess. You did not post a full compilable example which represents your
> problem, so it is difficult to find the problem. Please post a full
> program.
> 
> Also, there is a list template in the C++ Standard Library. Maybe you
> are coding your own list as an exercise, if not you should consider
> whether using std::list is an option.


Yes - It is an exercise.

[toc] | [prev] | [next] | [standalone]

#3018

"Ruben Safir" <ruben@mrbrklyn.com>
> I don't think I have a copy constructor, which might be the problem
> although it never had been.

Look up "rule of 3". If you have a dtor, you will need a copy cotor and 
operator= too, or must disable them.

[toc] | [prev] | [next] | [standalone]

#3021

On 03/04/2011 10:32, Balog Pal wrote:
> "Ruben Safir" <ruben@mrbrklyn.com>
>> I don't think I have a copy constructor, which might be the problem
>> although it never had been.
>
> Look up "rule of 3". If you have a dtor, you will need a copy cotor and
> operator= too, or must disable them.
>

Like most "rules" mentioned in this newsgroup the "rule of 3" is a 
nonsense: you may be adding a virtual dtor simply to make a base class 
polymorphic and have no need for a copy ctor and assignment operator or 
you may be relying on RAII and the behaviour of the implicitly defined 
special member functions.

/Leigh

[toc] | [prev] | [next] | [standalone]

#3079

Leigh Johnston Wrote:

> On 03/04/2011 10:32, Balog Pal wrote:
> > "Ruben Safir" <ruben@mrbrklyn.com>
> >> I don't think I have a copy constructor, which might be the
> >> problem although it never had been.
> >
> > Look up "rule of 3". If you have a dtor, you will need a copy cotor
> > and operator= too, or must disable them.
> >
> 
> Like most "rules" mentioned in this newsgroup the "rule of 3" is a 
> nonsense: 

That is putting it too strong.
The "rule of 3" is certainly not universally applicable, but you certainly
must keep it in mind when adding a destructor, copy-constructor or
copy-assignment operator to your class.

>you may be adding a virtual dtor simply to make a base class 
> polymorphic and have no need for a copy ctor and assignment
> operator or you may be relying on RAII and the behaviour of the
> implicitly defined special member functions.

Those are certainly situation where not all three of the mentioned member
functions are needed.
The best way to apply the "rule of three" is: Whenever you add a destructor,
copy-constructor or copy-assignment operator, check if the default behaviour
for the other two is suitable for your class. If not, define them
appropriately (or make them inaccessible)."

> 
> /Leigh

Bart v Ingen Schenau

[toc] | [prev] | [next] | [standalone]

#3139

On 4 avr, 13:43, Bart van Ingen Schenau <b...@ingen.ddns.info> wrote:
> Leigh Johnston Wrote:
>
> > On 03/04/2011 10:32, Balog Pal wrote:
> > > "Ruben Safir" <ru...@mrbrklyn.com>
> > >> I don't think I have a copy constructor, which might be the
> > >> problem although it never had been.
>
> > > Look up "rule of 3". If you have a dtor, you will need a copy cotor
> > > and operator= too, or must disable them.
>
> > Like most "rules" mentioned in this newsgroup the "rule of 3" is a
> > nonsense:
>
> That is putting it too strong.
> The "rule of 3" is certainly not universally applicable, but you certainly
> must keep it in mind when adding a destructor, copy-constructor or
> copy-assignment operator to your class.
>
> >you may be adding a virtual dtor simply to make a base class
> > polymorphic and have no need for a copy ctor and assignment
> > operator or you may be relying on RAII and the behaviour of the
> > implicitly defined special member functions.
>
> Those are certainly situation where not all three of the mentioned member
> functions are needed.
> The best way to apply the "rule of three" is: Whenever you add a destructor,
> copy-constructor or copy-assignment operator, check if the default behaviour
> for the other two is suitable for your class. If not, define them
> appropriately (or make them inaccessible)."

The original phrasing is:
http://drdobbs.com/cpp/184401400
The Rule of Three says that there are three member functions that go
together: the destructor, the copy constructor, and the assignment
operator. A class that defines a destructor should almost always
define the other two members. Moreover, a class that defines a copy
constructor or assignment operator should usually define the other two
members as well.

AFAIU the underlying idea if that classes should be in canonical form.

--
Michael

[toc] | [prev] | [next] | [standalone]

#3106

On Apr 3, 4:29 am, Leigh Johnston <le...@i42.co.uk> wrote:
> On 03/04/2011 10:32, Balog Pal wrote:
>
> > "Ruben Safir" <ru...@mrbrklyn.com>
> >> I don't think I have a copy constructor, which might be the problem
> >> although it never had been.
>
> > Look up "rule of 3". If you have a dtor, you will need a copy cotor and
> > operator= too, or must disable them.
>
> Like most "rules" mentioned in this newsgroup the "rule of 3" is a
> nonsense: you may be adding a virtual dtor simply to make a base class
> polymorphic and have no need for a copy ctor and assignment operator

In which case you probably want to prevent accidental slicing, and you
do that by defining a protected or private copy constructor and
assignment operator.

> or
> you may be relying on RAII and the behaviour of the implicitly defined
> special member functions.

I don't see an example here, just a hand wave, so I'm unable to verify
the veracity of your claims.

[toc] | [prev] | [next] | [standalone]

#3109

On Mon, 04 Apr 2011 14:03:26 -0700, Joshua Maurice wrote:


> In which case you probably want to prevent accidental slicing, 

what is accidental slicing

> and you
> do that by defining a protected or private copy constructor and
> assignment operator.
> 
>> or
>> you may be relying on RAII and the behaviour of the implicitly defined
>> special member functions.
> 
> I don't see an example here, just a hand wave, so I'm unable to verify
> the veracity of your claims.

Please, no flame war over this.  A simple request for an example would
suffice?  Nuh?

Ruben

[toc] | [prev] | [next] | [standalone]

#3112

On 04/04/2011 22:03, Joshua Maurice wrote:
> On Apr 3, 4:29 am, Leigh Johnston<le...@i42.co.uk>  wrote:
>> On 03/04/2011 10:32, Balog Pal wrote:
>>
>>> "Ruben Safir"<ru...@mrbrklyn.com>
>>>> I don't think I have a copy constructor, which might be the problem
>>>> although it never had been.
>>
>>> Look up "rule of 3". If you have a dtor, you will need a copy cotor and
>>> operator= too, or must disable them.
>>
>> Like most "rules" mentioned in this newsgroup the "rule of 3" is a
>> nonsense: you may be adding a virtual dtor simply to make a base class
>> polymorphic and have no need for a copy ctor and assignment operator
>
> In which case you probably want to prevent accidental slicing, and you
> do that by defining a protected or private copy constructor and
> assignment operator.
>
>> or
>> you may be relying on RAII and the behaviour of the implicitly defined
>> special member functions.
>
> I don't see an example here, just a hand wave, so I'm unable to verify
> the veracity of your claims.

If all of your class's member variables can be safely copied as-is, i.e. 
the implicitly defined special member functions work fine, then 
explicitly defining one of them (e.g. a virtual dtor) does not 
necessarily require explicit definitions of the other two.  Slicing is a 
red herring as just because a base class has a virtual dtor does not 
mean that the class must be derived from (i.e. if it is OK to create 
objects of the base class type as well as objects of the derived class 
type(s)).

/Leigh

[toc] | [prev] | [next] | [standalone]

#3108

On Sun, 03 Apr 2011 12:29:00 +0100, Leigh Johnston wrote:

> On 03/04/2011 10:32, Balog Pal wrote:
>> "Ruben Safir" <ruben@mrbrklyn.com>
>>> I don't think I have a copy constructor, which might be the problem
>>> although it never had been.
>>
>> Look up "rule of 3". If you have a dtor, you will need a copy cotor and
>> operator= too, or must disable them.
>>
>>
> Like most "rules" mentioned in this newsgroup the "rule of 3" is a
> nonsense: you may be adding a virtual dtor simply to make a base class
> polymorphic and have no need for a copy ctor and assignment operator or
> you may be relying on RAII and the behaviour of the implicitly defined
> special member functions.
> 
> /Leigh


Its hard for me to make that judgment though, without a more concrete
understanding of how destructors are triggered with auto values.

I'm not sure why any allocated memory created with new and dropped on 
the heap is auto destructed

Ruben

[toc] | [prev] | [next] | [standalone]

#3113

On 04/04/2011 22:07, Ruben Safir wrote:
> On Sun, 03 Apr 2011 12:29:00 +0100, Leigh Johnston wrote:
>
>> On 03/04/2011 10:32, Balog Pal wrote:
>>> "Ruben Safir"<ruben@mrbrklyn.com>
>>>> I don't think I have a copy constructor, which might be the problem
>>>> although it never had been.
>>>
>>> Look up "rule of 3". If you have a dtor, you will need a copy cotor and
>>> operator= too, or must disable them.
>>>
>>>
>> Like most "rules" mentioned in this newsgroup the "rule of 3" is a
>> nonsense: you may be adding a virtual dtor simply to make a base class
>> polymorphic and have no need for a copy ctor and assignment operator or
>> you may be relying on RAII and the behaviour of the implicitly defined
>> special member functions.
>>
>> /Leigh
>
>
> Its hard for me to make that judgment though, without a more concrete
> understanding of how destructors are triggered with auto values.
>
> I'm not sure why any allocated memory created with new and dropped on
> the heap is auto destructed
>

Well the typical example of when to use the rule of 3 is if you have a 
member variable pointer to allocated memory and it would be incorrect to 
copy that pointer from one object to another.  If this was a pointer to 
a dynamic array for example then I would use std::vector instead and the 
rule of 3 requirement disappears as vectors can be safely copied between 
objects.

/Leigh

[toc] | [prev] | [next] | [standalone]

#3114

On 04/04/2011 22:31, Leigh Johnston wrote:
> On 04/04/2011 22:07, Ruben Safir wrote:
>> On Sun, 03 Apr 2011 12:29:00 +0100, Leigh Johnston wrote:
>>
>>> On 03/04/2011 10:32, Balog Pal wrote:
>>>> "Ruben Safir"<ruben@mrbrklyn.com>
>>>>> I don't think I have a copy constructor, which might be the problem
>>>>> although it never had been.
>>>>
>>>> Look up "rule of 3". If you have a dtor, you will need a copy cotor and
>>>> operator= too, or must disable them.
>>>>
>>>>
>>> Like most "rules" mentioned in this newsgroup the "rule of 3" is a
>>> nonsense: you may be adding a virtual dtor simply to make a base class
>>> polymorphic and have no need for a copy ctor and assignment operator or
>>> you may be relying on RAII and the behaviour of the implicitly defined
>>> special member functions.
>>>
>>> /Leigh
>>
>>
>> Its hard for me to make that judgment though, without a more concrete
>> understanding of how destructors are triggered with auto values.
>>
>> I'm not sure why any allocated memory created with new and dropped on
>> the heap is auto destructed
>>
>
> Well the typical example of when to use the rule of 3 is if you have a
> member variable pointer to allocated memory and it would be incorrect to
> copy that pointer from one object to another. If this was a pointer to a
> dynamic array for example then I would use std::vector instead and the
> rule of 3 requirement disappears as vectors can be safely copied between
> objects.

Well vectors of trivial value_type I should have said; if the vector 
value_type also contains pointers that are unsafe to copy then the rule 
of 3 pops up again but a rule ceases to be a rule if there are 
sufficient exceptions IMO; I find the following wording acceptable though:

"If defining one of a dtor; cctor or assignment operator then check 
*whether* there is a need to define or disable the other two."

This is different to what was said earlier:

"If you have a dtor, you will *need* a copy cotor and operator= too, or 
*must* disable them."

which I do not find acceptable.

/Leigh

[toc] | [prev] | [next] | [standalone]

#3119

On Mon, 04 Apr 2011 22:31:35 +0100, Leigh Johnston wrote:

> On 04/04/2011 22:07, Ruben Safir wrote:
>> On Sun, 03 Apr 2011 12:29:00 +0100, Leigh Johnston wrote:
>>
>>> On 03/04/2011 10:32, Balog Pal wrote:
>>>> "Ruben Safir"<ruben@mrbrklyn.com>
>>>>> I don't think I have a copy constructor, which might be the problem
>>>>> although it never had been.
>>>>
>>>> Look up "rule of 3". If you have a dtor, you will need a copy cotor
>>>> and operator= too, or must disable them.
>>>>
>>>>
>>> Like most "rules" mentioned in this newsgroup the "rule of 3" is a
>>> nonsense: you may be adding a virtual dtor simply to make a base class
>>> polymorphic and have no need for a copy ctor and assignment operator
>>> or you may be relying on RAII and the behaviour of the implicitly
>>> defined special member functions.
>>>
>>> /Leigh
>>
>>
>> Its hard for me to make that judgment though, without a more concrete
>> understanding of how destructors are triggered with auto values.
>>
>> I'm not sure why any allocated memory created with new and dropped on
>> the heap is auto destructed
>>
>>
> Well the typical example of when to use the rule of 3 is if you have a
> member variable pointer to allocated memory and it would be incorrect to
> copy that pointer from one object to another.  If this was a pointer to
> a dynamic array for example then I would use std::vector instead and the
> rule of 3 requirement disappears as vectors can be safely copied between
> objects.
> 
> /Leigh



If a function creates a new object with new

class myobj{

obj * myfunct(){
	obj* a = new obj;
	return a;
}
}
myobj::~myobj(){
	delete a;
}

int main(int argv, char ** argc){

    obj * out;
    myobj * parent = new myobj;
    out = parent->myfunct();

  return 0;
}


Why should this be a problem?  The pointer of out should be addressing 
valid memory on the heap.

Ruben

[toc] | [prev] | [next] | [standalone]

#3120

On 04/04/2011 23:38, Ruben Safir wrote:
> On Mon, 04 Apr 2011 22:31:35 +0100, Leigh Johnston wrote:
>
>> On 04/04/2011 22:07, Ruben Safir wrote:
>>> On Sun, 03 Apr 2011 12:29:00 +0100, Leigh Johnston wrote:
>>>
>>>> On 03/04/2011 10:32, Balog Pal wrote:
>>>>> "Ruben Safir"<ruben@mrbrklyn.com>
>>>>>> I don't think I have a copy constructor, which might be the problem
>>>>>> although it never had been.
>>>>>
>>>>> Look up "rule of 3". If you have a dtor, you will need a copy cotor
>>>>> and operator= too, or must disable them.
>>>>>
>>>>>
>>>> Like most "rules" mentioned in this newsgroup the "rule of 3" is a
>>>> nonsense: you may be adding a virtual dtor simply to make a base class
>>>> polymorphic and have no need for a copy ctor and assignment operator
>>>> or you may be relying on RAII and the behaviour of the implicitly
>>>> defined special member functions.
>>>>
>>>> /Leigh
>>>
>>>
>>> Its hard for me to make that judgment though, without a more concrete
>>> understanding of how destructors are triggered with auto values.
>>>
>>> I'm not sure why any allocated memory created with new and dropped on
>>> the heap is auto destructed
>>>
>>>
>> Well the typical example of when to use the rule of 3 is if you have a
>> member variable pointer to allocated memory and it would be incorrect to
>> copy that pointer from one object to another.  If this was a pointer to
>> a dynamic array for example then I would use std::vector instead and the
>> rule of 3 requirement disappears as vectors can be safely copied between
>> objects.
>>
>> /Leigh
>
>
>
> If a function creates a new object with new
>
> class myobj{
>
> obj * myfunct(){
> 	obj* a = new obj;
> 	return a;
> }
> }
> myobj::~myobj(){
> 	delete a;
> }
>
> int main(int argv, char ** argc){
>
>      obj * out;
>      myobj * parent = new myobj;
>      out = parent->myfunct();
>
>    return 0;
> }
>
>
> Why should this be a problem?  The pointer of out should be addressing
> valid memory on the heap.
>

Sorry but I cannot make any sense of your reply; your code is ill-formed 
and I don't understand the question.

/Leigh

[toc] | [prev] | [next] | [standalone]

#3121

On Mon, 04 Apr 2011 22:38:06 +0000, Ruben Safir wrote:

> On Mon, 04 Apr 2011 22:31:35 +0100, Leigh Johnston wrote:
> 
>> On 04/04/2011 22:07, Ruben Safir wrote:
>>> On Sun, 03 Apr 2011 12:29:00 +0100, Leigh Johnston wrote:
>>>
>>>> On 03/04/2011 10:32, Balog Pal wrote:
>>>>> "Ruben Safir"<ruben@mrbrklyn.com>
>>>>>> I don't think I have a copy constructor, which might be the problem
>>>>>> although it never had been.
>>>>>
>>>>> Look up "rule of 3". If you have a dtor, you will need a copy cotor
>>>>> and operator= too, or must disable them.
>>>>>
>>>>>
>>>> Like most "rules" mentioned in this newsgroup the "rule of 3" is a
>>>> nonsense: you may be adding a virtual dtor simply to make a base
>>>> class polymorphic and have no need for a copy ctor and assignment
>>>> operator or you may be relying on RAII and the behaviour of the
>>>> implicitly defined special member functions.
>>>>
>>>> /Leigh
>>>
>>>
>>> Its hard for me to make that judgment though, without a more concrete
>>> understanding of how destructors are triggered with auto values.
>>>
>>> I'm not sure why any allocated memory created with new and dropped on
>>> the heap is auto destructed
>>>
>>>
>> Well the typical example of when to use the rule of 3 is if you have a
>> member variable pointer to allocated memory and it would be incorrect
>> to copy that pointer from one object to another.  If this was a pointer
>> to a dynamic array for example then I would use std::vector instead and
>> the rule of 3 requirement disappears as vectors can be safely copied
>> between objects.
>> 
>> /Leigh
> 
> 
> 
> If a function creates a new object with new
> 
> class myobj{
> 
> obj * myfunct(){
> 	obj* a = new obj;
> 	return a;
> }
> }
> myobj::~myobj(){
> 	delete a;
> }
> 
> int main(int argv, char ** argc){
> 
>     obj * out;
>     myobj * parent = new myobj;
>     out = parent->myfunct();
> 
>   return 0;
> }
> 
> 
> Why should this be a problem?  The pointer of out should be addressing
> valid memory on the heap.
> 
> Ruben

Actually - here is a more coherent example


#include<iostream>
#include<string>

class obj{
   public:
      obj():a(10), b("Hello World") {}
      int a;
      std::string b;
};

class myobj{

public:
myobj(){
   b = myfunct();
}

~myobj();
obj * b;

obj * myfunct(){
	obj* a = new obj;
	return a;
}
};
myobj::~myobj(){
	delete b;
}

int main(int argv, char ** argc){

    obj * out;
    obj * out2;

    myobj * parent = new myobj;
    out = parent->myfunct();
    out2 = parent->b;

   std::cout << out->a << " " << out->b << std::endl;

  return 0;
}

[toc] | [prev] | [next] | [standalone]

#3047

On Apr 3, 3:59 am, Ruben Safir <ru...@mrbrklyn.com> wrote:
> On Sat, 02 Apr 2011 15:29:26 +0200, Volker Lukas wrote:
> > Ruben Safir wrote:
> >> I am creating a linked link program which created a
> >> segmentation fault and a core at the end of the program.
> >> The program is trying to delete an already deleted object,
> >> and I can't seem to protect my program from this. I fixed
> >> the problem by sending an object to a function by reference
> >> rather than by value, but I'm not satisfied with the
> >> solution.
> > Why is the member "value_" in your Node template a pointer?

> Because by experience, pointers are easier to set to null
> which is needed from time to time as the end node should be
> null.

Why would you want such a node?  Typically, the last node in the
list will have a next pointer which is null, but all nodes which
exist will have a valid value.

> > Maybe you
> > forgot to clone this pointer in Nodes copy constructor.

> I don't think I have a copy constructor, which might be the
> problem although it never had been.

It depends.  Before trying to diagnose anything, it's necessary
to define what the class is supposed to do.

> The Nodes are separate from the list so when I pass the list
> by value, I created a new list object that when the function
> stopped, called the list destructor, destroying the nodes.
> When the program stopped, THEN the List destructor was called
> again and tried to destroy the same node.

What are the semantics of List?  Should it support deep copy, or
does copying result in a shared list?  (Or maybe it shouldn't
support copy at all.)  Until you decide on the semantics, it's
impossible to say what should be done.  (But it is likely that
List will require a copy constructor of some sort.)

--
James Kanze

[toc] | [prev] | [next] | [standalone]

#3110

On Sun, 03 Apr 2011 10:07:40 -0700, James Kanze wrote:


> Why would you want such a node?  Typically, the last node in the list
> will have a next pointer which is null, but all nodes which exist will
> have a valid value.

I think I already explained it as best as I could, and BTW, it is the 
same thing, more or less that vectors do with the allocate object.  There 
is good reasons for it.  If that is not suffice, then just decide that it 
is that way because the design specification requires it for no good 
reason.

Ruben

[toc] | [prev] | [next] | [standalone]

#3111

On Sun, 03 Apr 2011 10:07:40 -0700, James Kanze wrote:


> What are the semantics of List?  Should it support deep copy, or does
> copying result in a shared list?

It doesn't make much of difference, it seems, if it is doing a double 
delete.  That would seem to indicate that it must need a deep copy of all 
the nodes and the information, which is really not what I wanted.

Maybe if I make the copy constructor private, and operator=() that it 
might work better

Ruben

[toc] | [prev] | [next] | [standalone]

#3132

Ruben Safir wrote:
> On Sun, 03 Apr 2011 10:07:40 -0700, James Kanze wrote:
> 
> 
>> What are the semantics of List?  Should it support deep copy, or does
>> copying result in a shared list?
> 
> It doesn't make much of difference, it seems, if it is doing a double 
> delete.  That would seem to indicate that it must need a deep copy of all 
> the nodes and the information, which is really not what I wanted.
> 
> Maybe if I make the copy constructor private, and operator=() that it 
> might work better


Maybe you want some sort of smart shared pointer?

LR

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c++

csiph-web