a deconstructor question

Discussion in 'C++' started by Xiaoshen Li, Dec 30, 2005.

  1. Xiaoshen Li

    Xiaoshen Li Guest

    Dear All,

    I am a little confused.

    //Objects of this class are partially filled arrays of doubles
    class PFArray
    {
    public:
    ...
    ~PFArray();
    private:
    double *a; //for an array of doubles
    ..
    };

    PFArray::~PFArray()
    {
    delete [] a;
    }

    The code "double *a" in the private section of class PFArray doesn't
    NECESSARILY tell that a is a pointer to an array (it coulde be a pointer
    to a double, right?). Why the deconstructor use " delete [] a "? If a
    instead is pointer to a double, then "delete a" should be used?
     
    Xiaoshen Li, Dec 30, 2005
    #1
    1. Advertising

  2. Xiaoshen Li

    Xiaoshen Li Guest

    Thank you for the help. But I am not sure you are right.
    I took C++ class three years ago. Since then, I didn't use it.
    Yesterday, I saw the code in the class passed by the professor:

    class Person
    {
    public:
    ..
    ~Person();
    private:
    char *name;
    };

    Person::~Person()
    {
    delete [] name;
    }

    Since name could be pointing a single char or a char array, why the
    destructor uses "delete [] name"?

    Thank you again.
     
    Xiaoshen Li, Dec 30, 2005
    #2
    1. Advertising

  3. Xiaoshen Li

    Xiaoshen Li Guest

    Thank you very much, Mike.

    #include <string>
    using namespace std;

    class Person
    {
    publice:
    ...
    private:
    string name;
    int age;
    char gender;
    }

    With above class, is destructor needed or not? My guess is not, am I
    correct?

    Mike Wahler wrote:

    >
    > Anyway, you should not be using 'C-style' strings,
    > use a std::string object instead, then all the issues of
    > allocation/deallocation disappear (the std:: string objects
    > handle their own memory management for you automatically).
    >
    > #include <string>
    >
    > class Person
    > {
    > std::string name;
    > }; // no need for 'new' or 'delete'
    >
    > -Mike
    >
    >
     
    Xiaoshen Li, Dec 30, 2005
    #3
  4. Xiaoshen Li

    Xiaoshen Li Guest

    Could you kindly elaborate why "don't import std, instead use
    std::string"? Thank you very much.

    Paul Henderson wrote:
    > Nope, no destructor needed there, as name will delete its own buffer.
    > But don't import std...use std::string!
    >
     
    Xiaoshen Li, Dec 30, 2005
    #4
  5. Xiaoshen Li

    Mike Wahler Guest

    "Xiaoshen Li" <> wrote in message
    news:dp3k73$eq2j$...
    > Dear All,
    >
    > I am a little confused.
    >
    > //Objects of this class are partially filled arrays of doubles
    > class PFArray
    > {
    > public:
    > ...
    > ~PFArray();
    > private:
    > double *a; //for an array of doubles
    > ..
    > };
    >
    > PFArray::~PFArray()
    > {
    > delete [] a;
    > }
    >
    > The code "double *a" in the private section of class PFArray doesn't
    > NECESSARILY tell that a is a pointer to an array (it coulde be a pointer
    > to a double, right?).


    It *is* a pointer to type double. A pointer to an array would look like
    e.g:

    double (*a)[size];

    > Why the deconstructor use " delete [] a "?


    It should only use 'delete[]' if the value of the pointer
    'a' was returned 'new[]' or is NULL (0).
    Otherwise the behavior is undefined.

    > If a instead is pointer to a double, then "delete a" should be used?


    Only if 'a's value was returned by 'new' (not '[]').

    a = new double; // allocates a single type double object
    delete a; // deallocate the single type double object
    // delete[] a; // undefined behavior.

    a = new double[5]; // allocates array of five type double objects
    delete[] a; // deallocate the array of five doubles//
    delete a; // undefined behavior.

    double d;
    a = &d; // 'a's value not from 'new' or 'new[]'
    delete d; // undefined behavior
    delete[] d; // undefined behavior

    Which C++ book(s) are you reading?

    -Mike
     
    Mike Wahler, Dec 30, 2005
    #5
  6. Xiaoshen Li wrote:
    > Thank you for the help. But I am not sure you are right.


    He is.

    > I took C++ class three years ago. Since then, I didn't use it.
    > Yesterday, I saw the code in the class passed by the professor:
    >
    > class Person
    > {
    > public:
    > ..
    > ~Person();
    > private:
    > char *name;
    > };
    >
    > Person::~Person()
    > {
    > delete [] name;
    > }
    >
    > Since name could be pointing a single char or a char array, why the
    > destructor uses "delete [] name"?


    The rule is -- if you allocate with new[], you deallocate
    with delete[]. If you allocate with new, you deallocate with
    delete.

    Therefore the code by "the professor" is fine only if storage
    for 'name' is allocated with new[] (which is most probably
    the case).

    HTH,
    - J.
     
    Jacek Dziedzic, Dec 30, 2005
    #6
  7. Xiaoshen Li

    Mike Wahler Guest

    "Xiaoshen Li" <> wrote in message
    news:dp3ni9$17t5$...
    > Thank you for the help. But I am not sure you are right.


    Why not? What specifically did I state that you
    believe is not correct.

    > I took C++ class three years ago. Since then, I didn't use it. Yesterday,
    > I saw the code in the class passed by the professor:
    >
    > class Person
    > {
    > public:
    > ..


    What's the code you left out?

    > ~Person();
    > private:
    > char *name;
    > };
    >
    > Person::~Person()
    > {
    > delete [] name;
    > }
    >
    > Since name could be pointing a single char or a char array, why the
    > destructor uses "delete [] name"?


    Because it's assuming that 'name' was given a value by
    'new[]' (not 'new', nor the address operator). If this
    assumption proves false, the code is broken.

    Anyway, you should not be using 'C-style' strings,
    use a std::string object instead, then all the issues of
    allocation/deallocation disappear (the std:: string objects
    handle their own memory management for you automatically).

    #include <string>

    class Person
    {
    std::string name;
    }; // no need for 'new' or 'delete'

    -Mike
     
    Mike Wahler, Dec 30, 2005
    #7
  8. Nope, no destructor needed there, as name will delete its own buffer.
    But don't import std...use std::string!
     
    Paul Henderson, Dec 30, 2005
    #8
  9. Oh, just better practice in many people's opinion [though I might start
    an argument if I say that too strongly]. Basically, there's no point in
    *having* the std namespace if you're just going to include it at global
    scope everywhere, and there's a danger of symbol-name conflicts between
    your code and bits of std. But it doesn't really matter :)
     
    Paul Henderson, Dec 30, 2005
    #9
  10. Xiaoshen Li

    Gavin Deane Guest

    Paul Henderson wrote:

    <suggesting avoiding using namspace std>

    > Oh, just better practice in many people's opinion [though I might start
    > an argument if I say that too strongly]. Basically, there's no point in
    > *having* the std namespace if you're just going to include it at global
    > scope everywhere, and there's a danger of symbol-name conflicts between
    > your code and bits of std. But it doesn't really matter :)


    Please quote some context in your message.

    It is true that if you put a using directive or using declaration in
    your own source file, it only affects you. As long as you understand
    the issue, it's up to you whether you do it. However, the code that
    sparked this discussion was a class definition, which could well reside
    in a header file. If so, the argument for explicitly qualifying names
    from the std namespace in preference to a using directive or
    declaration should be made much more strongly.

    If you put using namespace std or even using std::string in a header
    file, *everyone* who includes your header file gets the namespace
    pollution, whether they want it or not. This is very different from you
    deciding to accept namespace pollution contained within your own source
    file.

    So it might be fair to say "But it doesn't really matter" if you are
    talking about a source file, particularly in a toy program you are
    writing for practice. But in a header file it really does matter. Don't
    put using directives or using declarations in header files.

    Gavin Deane
     
    Gavin Deane, Dec 30, 2005
    #10
  11. Xiaoshen Li wrote:
    > Dear All,
    >
    > I am a little confused.
    >
    > //Objects of this class are partially filled arrays of doubles
    > class PFArray
    > {
    > public:
    > ...
    > ~PFArray();
    > private:
    > double *a; //for an array of doubles
    > ..
    > };
    >
    > PFArray::~PFArray()
    > {
    > delete [] a;
    > }



    Put raw arrays away.
    Use std::vector for elements of type of double.

    Cheers
    --
    Mateusz Åoskot
    http://mateusz.loskot.net
     
    =?UTF-8?B?TWF0ZXVzeiDFgW9za290?=, Dec 30, 2005
    #11
  12. Xiaoshen Li wrote:
    > Thank you for the help. But I am not sure you are right.
    > I took C++ class three years ago. Since then, I didn't use it.


    Do you mean you didn't use delete[] ?
    Look here:
    http://www.softsurfer.com/Archive/algorithm_0205/#poly_simplify()

    Point* vt = new Point[n]; // vertex buffer
    int* mk = new int[n] = {0}; // marker buffer
    // ...
    delete vt;
    delete mk;

    There are still big amount of old code with this buggy way of destroying
    arrays: delete instead of delete[]

    > Since name could be pointing a single char or a char array, why the
    > destructor uses "delete [] name"?


    http://www.parashift.com/c -faq-lite/freestore-mgmt.html#faq-16.13

    Cheers
    --
    Mateusz Åoskot
    http://mateusz.loskot.net
     
    =?UTF-8?B?TWF0ZXVzeiDFgW9za290?=, Dec 30, 2005
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jonathan Mcdougall

    Re: Deconstructor Causing Crashes

    Jonathan Mcdougall, Jul 28, 2003, in forum: C++
    Replies:
    8
    Views:
    483
    Jonathan Mcdougall
    Jul 28, 2003
  2. Stofdeel

    Deconstructor and finalize

    Stofdeel, May 17, 2006, in forum: Java
    Replies:
    8
    Views:
    7,760
    Stofdeel
    May 17, 2006
  3. steflhermitte
    Replies:
    3
    Views:
    347
    Kristo
    Jun 21, 2005
  4. =?Utf-8?B?UGhpbGlw?=

    HttpModule Constructor/Deconstructor

    =?Utf-8?B?UGhpbGlw?=, Sep 10, 2007, in forum: ASP .Net
    Replies:
    0
    Views:
    441
    =?Utf-8?B?UGhpbGlw?=
    Sep 10, 2007
  5. Raymond O'connor

    Deconstructor to close file

    Raymond O'connor, Feb 19, 2007, in forum: Ruby
    Replies:
    11
    Views:
    205
    Robert Klemme
    Feb 20, 2007
Loading...

Share This Page