Thread: no change for private member ???

howdy, i built a class named LinearList and also declares some methods within, one of those is insert which can insert an element into the list

Code:

class LinearList
{
	public:
		LinearList(int size=0);
		~LinearList();
		bool isEmpty() const;
		bool isFull() const;
		int getLength() const;
		T getElement(int pos) const;
		int find(T ele) const;
		LinearList<T> insert(int pos, T ele);
		LinearList<T> remove(int pos);
		void trace();
	private:
		int __maxSize;
		int __length;
		T* __elements;
};
template <class T>
LinearList<T>::LinearList(int size)
{
	__maxSize = size;
	__length = 0;
	__elements = new T[__maxSize];
}
template <class T>
LinearList<T>::~LinearList()
{
	delete []__elements;
}
LinearList<T> LinearList<T>::insert(int pos, T ele)
{
	if (!isFull())
	{
		for (int i=__length-1; i>=pos; i--)
		{
			__elements[i+1] = __elements[i];
		}
		__elements[pos] = ele;
		__length++;
	}
	return *this;
}

all seems fine but after inserting by code like this:

Code:

list.insert(0, 5);

nothing changed with private member __elements, as if insert action didnt make any effect on it, what's wrong ???

Some potential problems:

You will need to define a copy constructor for this line:

return *this;

or it will have unwanted side effects. At best it does a shallow copy and you will end up with a pointer to your memory in both list instances that is deleted twice which will result in a crash.

Even if you define a copy constructor, copying the list each time you insert or remove is time consuming. Return a bool to signal if the element had been removed or inserted. After all, both operations can fail because the list is full or the position does not exist.


Your list is initialized to zero length if you leave the constructor empty. I'm a big fan of standard parameters and const correctness and you are using both here, which is great. However, a standard parameter should make sense and a list of size zero is not standard... it's simply unusable.

Make sure your methods for insertion and deletion return proper boolean values. Maybe your list is full when you insert ?

If that doesn't help, put in printf statements or jump into it with a debugger to find out if your logic fails at some point.


Edit: You might also consider marking your member variables different, because underscores and double underscores are reserved for compiler specific names I think.

i found reference return will help, like this:

Code:

class LinearList
{
	public:
		// ...
		LinearList<T>& insert(int pos, T ele);
                                // ...
	private:
		int __maxSize;
		int __length;
		T* __elements;
};

LinearList<T>& LinearList<T>::insert(int pos, T ele)
{
	if (!isFull())
	{
		for (int i=__length-1; i>=pos; i--)
		{
			__elements[i+1] = __elements[i];
		}
		__elements[pos] = ele;
		__length++;
	}
	return *this;
}

but i dont know why, since arrays are of reference type itself, it will change with code __elements[pos] = ele, regardless of what return type is, and i didnt even use return value of insert method in my code............confused

A problem persists... why would you return the list after inserting ? Why not return a bool ? You clearly have conditions in your function where inserting fails. Why hide that from the user ?

Return true is it was inserted, false if the list was full.
Check the returnvalue in your main program

Originally Posted by nvoigt

A problem persists... why would you return the list after inserting ? Why not return a bool ? You clearly have conditions in your function where inserting fails. Why hide that from the user ?

Return true is it was inserted, false if the list was full.
Check the returnvalue in your main program

thanx nvoigt i follows your advice and it was now fixed, here is the code:

Code:

bool LinearList<T>::insert(int pos, T ele)
{
	if (!isFull())
	{
		for (int i=__length-1; i>=pos; i--)
		{
			__elements[i+1] = __elements[i];
		}
		__elements[pos] = ele;
		__length++;
		return true;
	}
	return false;
}

why to return *this in previous one is becuase the example of my book did so, here is the original piece of code and i still didnt know the reason for returning *this

Code:

template <class T>
LinearList<T>& LinearList<T>::Insert(int k, const T& x)
{
    if (k < 0 || k > length) throw OutOfBounds();
    if (length == MaxSize) throw NoMem();
    for (int i=length-1; i>=k; i--)
    {
        element[i+1] = element[i];
    }
    element[k] = x;
    length++;
    return *this;
}

Regards~

The example in your book uses exceptions to report error conditions, so it doesn't have a need for a return value. For convenience it returns the list itself.
As you noticed already, it's always important to inform the rest of the program about your success. A step that silently fails is a danger for program integrity. However, which method you use, return values or exceptions sometimes is a matter of style. Both have their uses and as always, if you know when to use which technique, a good mixture is the key to success

Originally Posted by nvoigt

The example in your book uses exceptions to report error conditions, so it doesn't have a need for a return value. For convenience it returns the list itself.
As you noticed already, it's always important to inform the rest of the program about your success. A step that silently fails is a danger for program integrity. However, which method you use, return values or exceptions sometimes is a matter of style. Both have their uses and as always, if you know when to use which technique, a good mixture is the key to success

then could you please tell us what is the benefit to return the list itself instead ? i wonder about this for long and have no ideas on it

The benefit is really just in returning the list instead of returning void with the exceptions used in your example.

When the object itself is returned you can do operations on the returnvalue like this:

list.insert( X ).insert( Y );

instead of

list.insert( X );
list.insert( Y );

Thats probably a bad example, but basically, thats it... you can use the returnvalue right away.