Eliminating memory leaks

I am trying to prevent memory leaks with my code, but honestly, I'm a little weak on my understanding of pointers. In the class below, I am attempting to prevent any memory leaks when an element object is destroyed. Does setting the _parent pointer to NULL in the destructor accomplish this? Or does it make any difference? Or should I do something differently??

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63

/* Element Header */

#pragma once
#ifndef _ELEMENT_H
#define _ELEMENT_H

class element {
private:

	int _w, _h;
	point _p;
	element* _parent;

protected:

	inline void setWidth(int& w);
	inline void setHeight(int& h);

public:
	element() : _w(0), _h(0), _p(0,0), _parent(NULL) {};
	~element();
	
	inline int getWidth() const;
	inline int getHeight() const;

};


/* Constructors and Destructors *****************************************************************/
/************************************************************************************************/
element::~element() {
	_parent = NULL;
}


/* Dimension properties (width/height) **********************************************************/
/************************************************************************************************/
inline void element::setWidth(int& w) { 
	if (w <= 0) {
		_w = 1;
		if (DEBUG) std::cout << "[Element setWidth()] Width cannot be less than 0; reset to 1" << std::endl;
	} else {
		_w = w;
	}
}

inline void element::setHeight(int& h) {
	if (h <= 0) {
		_h = 1;
		if (DEBUG) std::cout << "[Element setHeight()] Height cannot be less than 0; reset to 1." << std::endl;
	} else {
		_h = h;
	}
}

inline int element::getWidth() const { return _w; }
inline int element::getHeight() const { return _h; }
/************************************************************************************************/



#endif 
If you use new, you must eventually use delete. If you use new[], you must eventually use delete[].

Is there a particular reason you are manually implementing a linked list instead of just using a std::vector?
Since, with the code provided, you never use _parent it really doesn't matter.

However if you someday actually added code that actually used that pointer it would probably be hazardous to just randomly assign that pointer to a nullptr value.
Element is a base class for Shape, which is a base class for Rectangles, Triangles, Circles, etc... This is part of a larger project I'm working on incorporating graphic programming. I'm just trying to eliminate any memory leaks early on. Also, this class *snipet* is a small part of the class. I didn't post the whole thing cause I only wanted the question about memory leaks addressed.

If you're curious (and perhaps have suggestions for improvement):
_parent helps track coordinates in relation to the window; needed for collision detection with buttons, combo boxes, etc.. For example, a button might be drawn onto an image, which is then drawn onto the window. Moving the image around never changes the coordinate position (_p) of the button in relation to the image, but it does change in relation to the window.. thus _parent keeps track of where in relation to the window the element is drawn.

1
2
3
4
5
6
7

/* Returns the position of this element relative to the window */
point element::getWindowPosition() const {
   point tmp = _p;
   if (getParent() != NULL) tmp += getParent()->getWindowPosition();
   return tmp;
}


I'm not using vectors since an element doesn't require a parent, or it might have many parents. A button drawn directly to the window (has no parent) will return it's _p as its windowPosition(). However, if it's drawn with layers of parents (such as cascading windows) it will still return it's relative window position correctly. And also, no parent is assigned until the element is actually drawn, since until that time, you don't know if it's parent will be another element or the window directly.
Last edited on
jib, as explained above, thanks.
Topic archived. No new replies allowed.