Thread: Doubly Linked List Deletion Issue

Ok, I wrote up a simple little program to use std::list but it shares the *exact* same problem as my code, except this takes up more memory, and doesn't create the nodes as fast... I am totally at a loss here.

iMalc, I'll try to stay away from using unconventional words in my function names, it is probably not a good idea.

Code:

#include "stdafx.h"
#include <iostream>
#include <list>

using namespace std;

struct Node
{
	string handle;
};

list <Node*> LIST;

void PushBackNode()
{
	LIST.push_back(new Node);
}

void PushBackNodes(unsigned long n)
{
	for(n;n>0;n--)
	{
		PushBackNode();
	}
}

int main()
{
	cout << "Creating nodes..." << endl;
	PushBackNodes(5);
	cout << " - " << endl;
	getchar();
	cout << "clearing nodes..." << endl;
	LIST.clear();
	cout << " - " << endl;
	getchar();
	return 0;
}

This code eats up around 670MB vs. my 434MB... and creates the nodes slightly slower, however the .clear() function "works" faster than my hombrew function, but at least mine releases 85% percent of the memory instead of 0%.

btw, the 'string handle' is just for comparing sizes, I did the same to my previous code which it where I'm getting my numbers.

you call new Node
but do not call delete on it, when you clear your list

Originally Posted by josephjah

Alright, I see. No, my original code didn't initialize them either, I didn't really have any reason for them to begin in a certain memory location. As long as I am keeping the value of NodeStart and NodeEnd preserved things should be ok right? Or should I still initialize them. And yeah, I fixed the NodeCount reset error, just a careless mistake.

Yeah you really do have to make sure that they are initialised to NULL at some point. How you do that depends on the real code of yours though. If they're member variables, use a constructor initializer list. If gobals, assign NULL in the declaration. I was once told strictly to always initialise my variables, even though I was using a language and compiler that always did that. It's advice you come to share after a while.

de·con·struct(dkn-strkt)
tr.v. de·con·struct·ed, de·con·struct·ing, de·con·structs
1. To break down into components; dismantle.

It isn't a spelling error, just used a different word at the time, and it stuck.

Oh of course, that is a real word, I almost forgot. Still in the context of C++ code it is fingernails on a blackboard for many people. Much safer to stick with 'destruct' all the time.

*sighs* Sorry.. After eliminating several hundred lines of unrelated code, variables, and definitions, I left a stray var. Oh well.

Sorry, didn't mean to be hard on you. Some of us just like to be thorough.

Well, I am using my LL code to attach different types of objects to each node which may themselves contain anything from strings to longs, to links to entirely different sublists.

I guess I could probably use it by just storing pointers to each newly created object in the list and then referencing them that way... But I would rather have this worked out because now I am curious... but it seems no one knows why it is behaving in such a strange way..

You can use a std::list in two ways.
Each node contains a pointer to your struct and a pointer to the next/prev nodes, or
Each node is essentially a structure that contains your struct as one of the members and the next/prev pointers as other members.
The later means that the memory allocation/deallocation is handled entirely with/by the list itself. The former means you allocate what the node points to and you delete it later.
Usually you would use the second method and store the object directly in the list. E.g. std::list<string> for a list of strings.
But if the list doesn't own the object (maybe this is just a sublist and they ALL appear in a different list anyway), then you use std::list<string*>

Still it's a good experience to write your own list, so I'd suggest keeping at it until it is sorted anyway. Well done sticking at it so far.