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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#3012

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? 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.

I think this outlines the bug

/*
 * =====================================================================================
 *
 *       Filename:  test_del.cpp
 *
 *    Description:  Testing DOuble Deletes
 *
 *        Version:  1.0
 *        Created:  04/02/2011 05:12:24 PM
 *       Revision:  none
 *       Compiler:  gcc
 *
 *         Author:  YOUR NAME Ruben Safir, 
 *        Company:  NYLXS
 *
 * =====================================================================================
 */



#ifndef  LINKLIST
#define LINKLIST
#include	"linklist.h"
#endif     /* -----  not LINKLIST  ----- */

#include	<iostream>
#include	<fstream>
#include 	<climits>
#include	<stdlib.h>

/* 
 * ===  FUNCTION  ======================================================================
 *         Name:  main
 *  Description:  
 * =====================================================================================
 */


chainlist::List<int> creating_int_list();
void find_all_examples(chainlist::List<int>, int);


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

   chainlist::List<int> outside = creating_int_list();
   outside.display();
   find_all_examples(outside, 4);

   outside.find_value(4);


   std::cout << "****************************************OUTSIDE**************************************************" << std::endl;
   chainlist::Node<int> * found = outside.cursor();
   std::cout << "Found first value ==> '" << *found->value() << "' at node =='" << outside.cursor() << std::endl;
   found = &(outside.find_next_value(4, *found)); 
   while( found ){ 
      std::cout << "Found next value ==> '" << *(found->value()) << "' at node =='" << outside.cursor() << std::endl;
      found = &(outside.find_next_value(4, *found));
   }

   return EXIT_SUCCESS;
}				/* ----------  end of function main  ---------- */


chainlist::List<int> creating_int_list(){
   // chainlist::List<int>  set = new chainlist::List<int>;
   chainlist::List<int>  set;
   srand(12345);
   int ran;
   for(int i = 0; i < 50000; ++i){
      ran=rand();
      set.insert(ran % 101);
   }
   return set;
}

void find_all_examples ( chainlist::List<int> glob, int search_value )
{
   glob.find_value(search_value);
   chainlist::Node<int> * found = glob.cursor();
   std::cout << "Found first value ==> '" << *found->value() << "' at node =='" << glob.cursor() << std::endl;
   found = &(glob.find_next_value(search_value, *found)); 
   while( found ){ 
      std::cout << "Found next value ==> '" << *(found->value()) << "' at node =='" << glob.cursor() << std::endl;
      found = &(glob.find_next_value(search_value, *found));
   }


   return ;
}		


/

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

#3017

Ruben Safir <ruben@mrbrklyn.com> wrote in
news:in8ob0$ju1$4@reader1.panix.com: 

> I think this outlines the bug

This does not compile (no linklist.h). It also does not contain any 
interesting functions. Show us the implementations of List's copy 
constructor and assignment operator instead.

cheers
Paavo



> 
> /*
>  * ====================================================================
>  ================= *
>  *       Filename:  test_del.cpp
>  *
>  *    Description:  Testing DOuble Deletes
>  *
>  *        Version:  1.0
>  *        Created:  04/02/2011 05:12:24 PM
>  *       Revision:  none
>  *       Compiler:  gcc
>  *
>  *         Author:  YOUR NAME Ruben Safir, 
>  *        Company:  NYLXS
>  *
>  * ====================================================================
>  ================= */
> 
> 
> 
> #ifndef  LINKLIST
> #define LINKLIST
> #include     "linklist.h"
> #endif     /* -----  not LINKLIST  ----- */
> 
> #include     <iostream>
> #include     <fstream>
> #include      <climits>
> #include     <stdlib.h>
> 
> /* 
>  * ===  FUNCTION 
>  ======================================================================
>  *         Name:  main
>  *  Description:  
>  * ====================================================================
>  ================= */
> 
> 
> chainlist::List<int> creating_int_list();
> void find_all_examples(chainlist::List<int>, int);
> 
> 
> int main ( int argc, char *argv[] )
> {
> 
>    chainlist::List<int> outside = creating_int_list();
>    outside.display();
>    find_all_examples(outside, 4);
> 
>    outside.find_value(4);
> 
> 
>    std::cout <<
>    "****************************************OUTSIDE********************
>    ******************************" << std::endl; chainlist::Node<int>
>    * found = outside.cursor(); std::cout << "Found first value ==> '"
>    << *found->value() << "' at node =='" << outside.cursor() <<
>    std::endl; found = &(outside.find_next_value(4, *found)); 
>    while( found ){ 
>       std::cout << "Found next value ==> '" << *(found->value()) << "'
>       at node =='" << outside.cursor() << std::endl; found =
>       &(outside.find_next_value(4, *found)); 
>    }
> 
>    return EXIT_SUCCESS;
> }                    /* ----------  end of function main  ----------
> */ 
> 
> 
> chainlist::List<int> creating_int_list(){
>    // chainlist::List<int>  set = new chainlist::List<int>;
>    chainlist::List<int>  set;
>    srand(12345);
>    int ran;
>    for(int i = 0; i < 50000; ++i){
>       ran=rand();
>       set.insert(ran % 101);
>    }
>    return set;
> }
> 
> void find_all_examples ( chainlist::List<int> glob, int search_value )
> {
>    glob.find_value(search_value);
>    chainlist::Node<int> * found = glob.cursor();
>    std::cout << "Found first value ==> '" << *found->value() << "' at
>    node =='" << glob.cursor() << std::endl; found =
>    &(glob.find_next_value(search_value, *found)); while( found ){ 
>       std::cout << "Found next value ==> '" << *(found->value()) << "'
>       at node =='" << glob.cursor() << std::endl; found =
>       &(glob.find_next_value(search_value, *found)); 
>    }
> 
> 
>    return ;
> }          
> 
> 
> /

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

#3019

Ruben Safir 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? 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.
> 
> I think this outlines the bug
Unfortunately, I still can not get this to compile because many 
functions are unimplemented. I think I can say that the problem is that 
inside your List object you are storing pointers to the nodes. When you 
pass this object to a function by value a second object, a copy is 
created, which stores the same pointer values (since you did not define 
a copy constructor). Now you have two objects whose destructors will 
both attempt to delete the same objects. That is an error.

If you need a definite answer you need to post a full compilable 
example, something which can be saved verbatim in a file which can be 
compiled.

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

#3020

Am 03.04.2011 05:08, schrieb Ruben Safir:
>
> #ifndef  LINKLIST
> #define LINKLIST
> #include	"linklist.h"
> #endif     /* -----  not LINKLIST  ----- */

Include guards should be inside the header, not outside it in the source?


Peter

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

#3063

Peter Remmers wrote:
>Am 03.04.2011 05:08, schrieb Ruben Safir:
>> #ifndef  LINKLIST
>> #define LINKLIST
>> #include	"linklist.h"
>> #endif     /* -----  not LINKLIST  ----- */
>
>Include guards should be inside the header, not outside it in the source?

It "should" be done either way.
In older, slower systems, (think compiling from very slow disks, or
even slower floppies,) it was common to use this approach to skip
reading the included file altogether.
With the multiple inclusion guards in the header file being protected,
the compiler/preprocessor still needs to read the whole file and scan
it for any preprocessing directives.
--
Roberto Waltman

[ Please reply to the group,
  return address is invalid ]

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

#3810

On Sun, 03 Apr 2011 18:16:58 -0400, Roberto Waltman wrote:

> Peter Remmers wrote:
>>Am 03.04.2011 05:08, schrieb Ruben Safir:
>>> #ifndef  LINKLIST
>>> #define LINKLIST
>>> #include	"linklist.h"
>>> #endif     /* -----  not LINKLIST  ----- */
>>
>>Include guards should be inside the header, not outside it in the
>>source?
> 
> It "should" be done either way.
> In older, slower systems, (think compiling from very slow disks, or even
> slower floppies,) it was common to use this approach to skip reading the
> included file altogether. With the multiple inclusion guards in the
> header file being protected, the compiler/preprocessor still needs to
> read the whole file and scan it for any preprocessing directives.

I just had a problem pop up where all my templates were coming up with 
redefinition errors.  The problem stopped when I moved the #endif to the 
bottom of the file.  Why would I see that behavior?

ruben

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

#3811

Ruben Safir wrote:
> On Sun, 03 Apr 2011 18:16:58 -0400, Roberto Waltman wrote:
> 
>> Peter Remmers wrote:
>>> Am 03.04.2011 05:08, schrieb Ruben Safir:
>>>> #ifndef  LINKLIST
>>>> #define LINKLIST
>>>> #include	"linklist.h"
>>>> #endif     /* -----  not LINKLIST  ----- */
>>>
>>> Include guards should be inside the header, not outside it in the
>>> source?
>>
>> It "should" be done either way.
>> In older, slower systems, (think compiling from very slow disks, or even
>> slower floppies,) it was common to use this approach to skip reading the
>> included file altogether. With the multiple inclusion guards in the
>> header file being protected, the compiler/preprocessor still needs to
>> read the whole file and scan it for any preprocessing directives.
> 
> I just had a problem pop up where all my templates were coming up with 
> redefinition errors.  The problem stopped when I moved the #endif to the 
> bottom of the file.  Why would I see that behavior?

You're probably including linklist.h more than once in the file you're
trying to compile.

http://en.wikipedia.org/wiki/Include_guard

LR

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

#3809

On Sun, 03 Apr 2011 12:14:40 +0200, Peter Remmers wrote:

> Am 03.04.2011 05:08, schrieb Ruben Safir:
>>
>> #ifndef  LINKLIST
>> #define LINKLIST
>> #include	"linklist.h"
>> #endif     /* -----  not LINKLIST  ----- */
> 
> Include guards should be inside the header, not outside it in the
> source?
> 
> 
> Peter

please explain

should the #endif be at the end of the file and why?

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

#3813

* Ruben Safir, on 16.04.2011 01:03:
> On Sun, 03 Apr 2011 12:14:40 +0200, Peter Remmers wrote:
>
>> Am 03.04.2011 05:08, schrieb Ruben Safir:
>>>
>>> #ifndef  LINKLIST
>>> #define LINKLIST
>>> #include	"linklist.h"
>>> #endif     /* -----  not LINKLIST  ----- */
>>
>> Include guards should be inside the header, not outside it in the
>> source?
>
> please explain
>
> should the #endif be at the end of the file and why?

It depends on whether it's an external include guard (where you're including the 
header) or an internal include guard (the ordinary kind of include guard, in the 
header file). The idea in any case is to ensure that the text of the header is 
included only once. You can figure it out from there.

External include guards were discussed in Lakos' "Large scale software design". 
They're no longer much used. Compiler technology has improved.

For an internal include guard the usual pattern is now


   #ifndef SOME_UNIQUE_SYMBOL
   #define SOME_UNIQUE_SYMBOL

   //... text of header file

   #endif


An alternative that is /non-standard/ and /not entirely reliable/, but that is 
textually much cleaner, is to use a '#pragma once', like so:


   #pragma once

   //... text of header file


The pragma is problematic when one employs symbolic links to files. The compiler 
may then be unable to detect that two or more links yield the same file. Hence, 
the pragma may be preferable for a small personal project, but not as the single 
single-include-measure for a larger project with more devlopers involved (some 
of whom may suddenly be using symbolic links). When combined with internal 
include guards it may however reduce build times, and it may be necessary due to 
non-standard behavior such as Microsoft's "precompiled headers". Whether it 
actually does reduce build times or have other beneficial or necessary effect, 
depends on the compiler etc.


Cheers & hth.,

- Alf

-- 
blog at <url: http://alfps.wordpress.com>

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

#3823

Am 16.04.2011 01:47, schrieb Alf P. Steinbach /Usenet:
> * Ruben Safir, on 16.04.2011 01:03:
>>  On Sun, 03 Apr 2011 12:14:40 +0200, Peter Remmers wrote:
>>
>>>  Am 03.04.2011 05:08, schrieb Ruben Safir:
>>>>
>>>>  #ifndef  LINKLIST
>>>>  #define LINKLIST
>>>>  #include	"linklist.h"
>>>>  #endif     /* -----  not LINKLIST  ----- */
>>>
>>>  Include guards should be inside the header, not outside it in the
>>>  source?
>>
>>  please explain
>>
>>  should the #endif be at the end of the file and why?
>
> It depends on whether it's an external include guard (where you're including the
> header) or an internal include guard (the ordinary kind of include guard, in the
> header file). The idea in any case is to ensure that the text of the header is
> included only once. You can figure it out from there.
>
> External include guards were discussed in Lakos' "Large scale software design".
> They're no longer much used. Compiler technology has improved.

They also have several disadvantages:
- You would need to put a guard around each #include for every file that 
does not employ its own internal guard
- You would need to put a guard around each #include occurrence for a 
certain header, in every source and every other spot where you include it
- You would need to make sure that you use exactly the same macro for 
each occurrence

This is unnecessarily troublesome and totally error prone. Not to 
mention unreadable.

> For an internal include guard the usual pattern is now
>
>
>     #ifndef SOME_UNIQUE_SYMBOL
>     #define SOME_UNIQUE_SYMBOL
>
>     //... text of header file
>
>     #endif
>
>
> An alternative that is /non-standard/ and /not entirely reliable/, but that is
> textually much cleaner, is to use a '#pragma once', like so:
>
>
>     #pragma once
>
>     //... text of header file
>
>
> The pragma is problematic when one employs symbolic links to files.
Why would anyone do such a thing?

>The compiler
> may then be unable to detect that two or more links yield the same file. Hence,
> the pragma may be preferable for a small personal project, but not as the single
> single-include-measure for a larger project with more devlopers involved (some
> of whom may suddenly be using symbolic links). When combined with internal
> include guards it may however reduce build times, and it may be necessary due to
> non-standard behavior such as Microsoft's "precompiled headers". Whether it
> actually does reduce build times or have other beneficial or necessary effect,
> depends on the compiler etc.
>
>
> Cheers&  hth.,
>
> - Alf
>


Peter

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

#3825

* Peter Remmers, on 16.04.2011 13:00:
> Am 16.04.2011 01:47, schrieb Alf P. Steinbach /Usenet:
>>
>> An alternative that is /non-standard/ and /not entirely reliable/, but that is
>> textually much cleaner, is to use a '#pragma once', like so:
>>
>>
>> #pragma once
>>
>> //... text of header file
>>
>>
>> The pragma is problematic when one employs symbolic links to files.
>
> Why would anyone do such a thing?

Well, people have stated directly (on SO) that they do employ symbolic links and 
prefer that. But as far as I recall they have not stated why they employ 
symbolic links, except for general convenience. So this is speculation, but 
consider a library of sublibries, where one would like usage to be like

   #include <vendor/sublibrary/module.h>

Then the directory structure for development might be like

     bigLibrary
         library1
             vendor
                 library1    -> files like [module.h]
         library2
             vendor
                 library2
         library3
             vendor
                 library3

For example, as I recall you find that kind of directory structure for the 
version 2 things in the OpenCV library.

It allows each of the library1 etc. directories to be placed just about anywhere 
and worked on independently, not just as parts of bigLibrary.

But for usage it's a nuisance to set up include paths to all of library1, 
library2, library3 etc. For usage you might therefore instead have

     bigLibrary
         include
             vendor
                 library1  as link to impl/bigLibrary/library1/vendor/library1
                 library2  as link to impl/bigLibrary/library2/vendor/library2

and set up include file search path only to bigLibrary/include directory.

In Windows XP and earlier this is a bit difficult to do  --  no symlinks! But 
the masochistic developer can set up folders that redirect to folders. He he.

<example>
C:\test> md a

C:\test> echo This is the 'a' directory... >a\description.txt

C:\test> which linkd.exe
C:\Program Files\Windows Resource Kits\Tools\linkd.exe

C:\test> md b

C:\test> linkd b a
Link created at: b

C:\test> cd b

C:\test\b> type description.txt
This is the 'a' directory...

C:\test\b> _
</example>


Disclaimer: I haven't tested that for includes. And the idea that this might be 
the reason for people using symlinks is, as I wrote, just speculation. A 
possibility.


Cheers & hth.,

- Alf

-- 
blog at <url: http://alfps.wordpress.com>

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

#2999

Ruben Safir wrote:

> I created a large list to test my find functions and passed it by value
> to main.

I don't understand that.  How did you pass a list by value to main? Did
you create a function to make the list and then copy construct it inside
main?

> Then passed it by value to a find testing function. 

So now there are two copies of the list?

> when the program ends,
> it seems to delete all the nodes from the List twice, once from the local
> program and then from main.

From the local program? I'm not sure what a local program is.

Shouldn't the copy that you passed to your find testing function have
been destroyed when it went out of scope? And then the list you say you
passed to main by value? Wouldn't that would be two copies being destroyed?

I find it useful to not put my test code directly in main(), but to put
it in a function that is called by main().  Then I can either set
breakpoints that show when things are destroyed or put some output
around the call to the test function.

You may also benefit from putting some io code in your ctors and dtors
that show the address and maybe the data of each object being created
and destroyed.


> 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. 

Why is that a problem?



> There has to be a better strategy for
> handling this issue.

LR

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

#3083

On 2011-04-02, Ruben Safir <ruben@mrbrklyn.com> 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.
>
> 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! */

Stop here!

Could you clarify to us why the following comments is there: 
/* copy constructor - Need to write this! */


Yannick

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

#3107

On Mon, 04 Apr 2011 12:56:41 +0000, Yannick Tremblay wrote:

> On 2011-04-02, Ruben Safir <ruben@mrbrklyn.com> 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.
>>
>> 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! */
> 
> Stop here!
> 
> Could you clarify to us why the following comments is there: /* copy
> constructor - Need to write this! */
> 
> 
> Yannick

Because I haven't written it yet.

The purpose of the question is to understand what is happening, not to necessarily
fix the program.  This is not a homework assignment with a deadline.  I just want to
have a better understanding of why the destructor caused a double delete.

The entire exercise I believe is in here 
http://www.nylxs.com/docs/workshops/linklist_templates_mysql/

Ruben

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

#3129

Ruben Safir <ruben@mrbrklyn.com> wrote in
news:indbq3$r87$2@reader1.panix.com: 

> The purpose of the question is to understand what is happening, not to
> necessarily fix the program.  This is not a homework assignment with a
> deadline.  I just want to have a better understanding of why the
> destructor caused a double delete. 

Ok, that makes the things clearer. I try to explain.

Basically, for every 'new'-ed pointer value there must be a corresponding 
single 'delete'. If an object contains a 'new'-ed pointer as a data 
member and if the object gets copied (as in your example when you passed 
it to somewhere else by value) one will have two copies of the object, 
which both contain the same pointer value. Eventually both objects get 
destroyed, and each destructor call calls delete with the same pointer 
value, resulting in double-delete.

The crucial point is that the object copying is done by the compiler-
generated copy constructor, which effectively only copies the bit 
patterns of all members of built-in types, including raw pointers. This 
would be fine if the pointer points to a shared or global object having 
an independent lifetime. However, the compiler won't analyze your code in 
detail and find out if this is the case or not. In general, this would 
require a lot more intelligence from the compiler than is currently 
provided by vendors. It is the programmer who is responsible for defining 
a custom copy ctor if it is needed and the compiler-generated one is not 
suitable. If copy ctor is not needed, it is a very good idea to prohibit 
the compiler-generated version by e.g. deriving from boost::noncopyable, 
in order to avoid accidental usage.

The same holds for the assignment operator, it is just slightly more 
trickier to implement.

hth
Paavo

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

#3147

On 2011-04-04, Ruben Safir <ruben@mrbrklyn.com> wrote:
> On Mon, 04 Apr 2011 12:56:41 +0000, Yannick Tremblay wrote:
>
>>> ======================================= /* constructor */
>>> Node<unk>( unk value, Node<unk> *item_to_link_to = 0); Node ( const
>>> Node &other ); /* copy constructor - Need to write this! */
>> 
>> Stop here!
>> 
>> Could you clarify to us why the following comments is there: /* copy
>> constructor - Need to write this! */
>
> Because I haven't written it yet.
>
> The purpose of the question is to understand what is happening, not to necessarily
> fix the program.  This is not a homework assignment with a deadline.  I just want to
> have a better understanding of why the destructor caused a double delete.

This was a leading question.  

copy-constructor are not always needed for all classes.  However, for
some classes a copy constructor is absolutely needed.

Here you have a header file that explicitely says (correctly given the
your class contains raw pointers) that the copy contructor need to be
written.  I am not sure if you wrote it yourself as a reminder or if
it was a format that was specified externally from a template that
attempt to remind peoples that they should write copy-constructors.  

Regardless, despite the presence of this reminder, you have not
written the copy-constructor. That should very probably be your first
point of call.  

Your destructor cause double delete because your copy constructor and
your destructor are incompatible.  Write a copy-constructor that is
compatible with your destructor or write a copy-constructor and modify
your destructor so both are compatible and you will not have a bug
anymore.  

So essentially you have a Node that contains a pointer to value and a
pointer to next.  You have a destructor that delete the pointer to
value.

What currently happens if you copy a node?  
(hint: compiler generated copy constructor)
(hint: what will be the values of value_ and next_ in the copy and in
the original?)

What will happen if you delete this node copy?

What will happen if you delete the original node?


Yannick

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

#3164

On Tue, 05 Apr 2011 11:36:48 +0000, Yannick Tremblay wrote:

> On 2011-04-04, Ruben Safir <ruben@mrbrklyn.com> wrote:
>> On Mon, 04 Apr 2011 12:56:41 +0000, Yannick Tremblay wrote:
>>
>>>> ======================================= /* constructor */ Node<unk>(
>>>> unk value, Node<unk> *item_to_link_to = 0); Node ( const Node &other
>>>> ); /* copy constructor - Need to write this! */
>>> 
>>> Stop here!
>>> 
>>> Could you clarify to us why the following comments is there: /* copy
>>> constructor - Need to write this! */
>>
>> Because I haven't written it yet.
>>
>> The purpose of the question is to understand what is happening, not to
>> necessarily fix the program.  This is not a homework assignment with a
>> deadline.  I just want to have a better understanding of why the
>> destructor caused a double delete.
> 
> This was a leading question.
> 
> copy-constructor are not always needed for all classes.  However, for
> some classes a copy constructor is absolutely needed.
> 
> Here you have a header file that explicitely says (correctly given the
> your class contains raw pointers) that the copy contructor need to be
> written.  I am not sure if you wrote it yourself as a reminder or if it
> was a format that was specified externally from a template that attempt
> to remind peoples that they should write copy-constructors.

Thanks for replying.

It so happens, that in this case, the original linked list example in 
Lippman privatized the copy constructor and assignment operator in order 
to prevent them from being called.  When I branched off the original 
example, I decided that I'd write a copy constructor so that I can define 
that behavior, but I haven't gotten to it.  I did not know at that time 
that this would be something that would cause such a bug in the program 
that it was a vital need to be addressed.

But I'm distressed at this point because I don't want two copies of all 
the nodes.  I want one series of nodes, which are created in free memory 
on the stack, handled in all possible scopes.  The nodes themselves are 
'self aware" of their positions in the list in that they have the 
information of they're position in the nodes.  The List object itself 
does nothing more that communicate with the nodes.  If I copy the List 
Object, I don't want to duplicate the nodes as well.  They're on the 
heap, and then can stay there.

> 
> Regardless, despite the presence of this reminder, you have not written
> the copy-constructor. That should very probably be your first point of
> call.
> 
> Your destructor cause double delete because your copy constructor and
> your destructor are incompatible.  Write a copy-constructor that is
> compatible with your destructor or write a copy-constructor and modify
> your destructor so both are compatible and you will not have a bug
> anymore.
> 
> So essentially you have a Node that contains a pointer to value and a
> pointer to next.  You have a destructor that delete the pointer to
> value.
> 
> What currently happens if you copy a node? (hint: compiler generated
> copy constructor) (hint: what will be the values of value_ and next_ in
> the copy and in the original?)
> 
> What will happen if you delete this node copy?
> 
> What will happen if you delete the original node?
> 
> 
> Yannick

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

#3172

On Apr 5, 11:40 am, Ruben Safir <ru...@mrbrklyn.com> wrote:
>
> But I'm distressed at this point because I don't want two copies of all
> the nodes.  I want one series of nodes, which are created in free memory
> on the stack, handled in all possible scopes.  The nodes themselves are
> 'self aware" of their positions in the list in that they have the
> information of they're position in the nodes.  The List object itself
> does nothing more that communicate with the nodes.  If I copy the List
> Object, I don't want to duplicate the nodes as well.  They're on the
> heap, and then can stay there.
>

Make your copy constructor private. This will forbid passing the list
by value. So you will have to pass the list by reference.

/d

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

#3186

On Tue, 05 Apr 2011 19:21:53 +0200, Volker Lukas wrote:

> Ruben Safir wrote:
> ...
>> But I'm distressed at this point because I don't want two copies of all
>> the nodes.  I want one series of nodes, which are created in free
>> memory
>> on the stack, handled in all possible scopes.  The nodes themselves are
>> 'self aware" of their positions in the list in that they have the
>> information of they're position in the nodes.  The List object itself
>> does nothing more that communicate with the nodes.  If I copy the List
>> Object, I don't want to duplicate the nodes as well.  They're on the
>> heap, and then can stay there.
> In this case, you could split your List class in a frontend and a
> backend. The frontend stores a e.g. a shared_ptr to the backend and
> forwards all functions like insert, remove, ... to the backend class. Or
> you could just use a non-copyable List class and have all users of this
> class use shared_ptrs directly. Something like this (untested):
> 
> class List {
>  List& operator=(List const&);
>  List(List const&);
> 
>  public:
>  static shared_ptr<List> make() { return shared_ptr<List>(new List); }
>  
>  // Rest of implementation here...
> };

In a way, that is a completely different kind of construction and I'll give
this some thought.  It might be advantageous to have a non-copiable
struct of pointers....that can be passed to only front end object.

Or it is possible that this would be redundant.

Ruben

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

#3204

On 2011-04-05, Ruben Safir <ruben@mrbrklyn.com> wrote:
>
> But I'm distressed at this point because I don't want two copies of all 
> the nodes.  I want one series of nodes, which are created in free memory 
> on the stack, handled in all possible scopes.  The nodes themselves are 
> 'self aware" of their positions in the list in that they have the 
> information of they're position in the nodes.  The List object itself 
> does nothing more that communicate with the nodes.  If I copy the List 
> Object, I don't want to duplicate the nodes as well.  They're on the 
> heap, and then can stay there.

Are you sure about the behaviour you want?

You have a List.
The list contains Nodes.
The Nodes contain a pointer to some data.

What behaviour do you want when you copy a list?

What behavious do you want when you copy a node?

What behaviour do you want when you destroy a list?

What behaviour do you want when you destroy a node?

Don't worry about optimization for now.  Worry about correctness and
consistency. 

Does the Node own the data it points to? 
- If yes: then the node most delete the data when the node gets
destroyed
- If no: the node only refers to the data that is external.  The node
can go away without affecting the data.  Lifetime management of the
data is done separately.

Should modifying a copy of a list affect the original list?
     List list1;
     // add ten element to list1;
     assert(list1.size() == 10);
     List list2 = list1;  // Create a copy
     assert(list2.size() == list1.size()); // definite at this point
    
     // remove 2 element from list2
     assert(list2.size() == 8);

     // What about list1?  Should it still contain 10 elements or 8?

Does the list owns the nodes it contains?

etc.

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web