0

I've attempted to overload the "+" operator for template. Yet I get a debug error abort() has been called. The "+" operator should add an item to the end of the list, then return the result.

So if I'm right, let's assume list1 has integer items of {4,2,1}. I am guessing writing myList<int> list2 = list1 + 5 should make list2 contain the items {4,2,1,5}

template <class type>
class myList
{
protected:
    int length;         //the number of elements in the list
    type *items;        //dynamic array to store the elements

public:
    myList();

    //adds one element to a list
    friend myList& operator+ (myList<type> &lhs, const type& t) 
    {
        myList<type> result;
        if (lhs.items == NULL)
        {
            result.items = new type[1];
            result.items[0] = t;
            result.length++;
        }
        else
        {
            type *temp = new type[lhs.length];
            for (int i = 0; i < lhs.length; i++)
            {
                temp[i] = lhs.items[i];
            }
            result.items = new type[lhs.length + 1];
            for (int i = 0; i < lhs.length; i++)
            {
                result.items[i] = temp[i];
            }
            result.items[lhs.length] = t;
            result.length++;
        }
        return result;
    }
}

template <class type>
myList<type>::myList()
{
    length = 0;
    items = new type;
    items = NULL;
}

So what should be done in this case?

EDIT: I fixed it. I had to remove & from the return type. Is there any other possible way to fix it? or must & be removed?

BeLambda
  • 887
  • 1
  • 10
  • 19
  • The only bug in your `operator+` is a horrible memory leak. But that wouldn't cause a crash by itself. Just because your code crashes in the `+` operator doesn't mean that's where the bug is. Your bug that corrupts memory could be anywhere, but execution continued unaffected until the additional memory allocations (and excessive ones too, thanks to the memory leak) hit the corrupted heap, and blow up at this point. But the memory corruption bug is not here. – Sam Varshavchik Jun 28 '16 at 02:35
  • I have about 5 other functions and 1 member operator overload functions for +=. They all work fine on the tester, but only this operator+ is giving me issues. As for the memory leak, do you suggest I should use delete [] result.items to fix the memory leak? I just didn't include that due some other errors I had before, but I'll try again. – BeLambda Jun 28 '16 at 02:38
  • 1
    Just because they seem to "work fine" does not necessarily mean that they're bug free. As I explained, they could still accomplish their stated goal, but corrupt the heap, which wouldn't get detected until here. I could easily write an innocent function that does some array operation, seemingly successfully, but it also craps all over the heap and the code won't crash until some point later. Also, I didn't look very closely, but each call to `operator+` could, in some cases, leak twice. The best way to avoid memory leaks is to use containers, instead of allocating memory yourself. – Sam Varshavchik Jun 28 '16 at 02:43
  • 1
    There's at least two bugs I can see; `result.length++;` should be `result.length = lhs.length + 1;` and you return a reference to a local variable - the second is probably causing your crash. Oh, and if you are using `gdb`, `catch throw` will breakpoint your code at the point of the error. – Ken Y-N Jun 28 '16 at 02:46
  • @KenY-N can you elaborate on what you mean by return a reference to a local variable? – BeLambda Jun 28 '16 at 02:56
  • @user3015986 please [refer to this answer](http://stackoverflow.com/a/4643721/1270789). – Ken Y-N Jun 28 '16 at 03:00
  • @SamVarshavchik , @KenY-N I fixed it. Removing & from the return type of `friend myList& operator+ (myList &lhs, const type& t) ` takes away the error, and the whole thing works just as expected. I'm wondering why that would be? The code `friend myList& operator+ (myList &lhs, const type& t) ` was given by my instructor, which makes me question whether if it was his typo or I could have done something else. – BeLambda Jun 28 '16 at 03:19

0 Answers0