Linked lists,polynoms ,overloading operators << and >> in C++

Question

I have to build a class polynom (polinom) inherited from class lista (list). I have to add , substract ,multiply , divide 2 objects from the polynom class. I have this piece of code. I don't understand why my destructors aren't working. I also have to overload the operators: +,-,<<,>> but I don't know how to.

#include <iostream>
#include <conio.h>

using namespace std;

struct nod
{float coef;
 int grad;
 nod* adr_urm;
};

class lista
{ 
public:
   nod *vf,*sf;
   lista();
   nod* adaug(nod *&vf,nod*& sf , int gr,float cf);
   void afis(nod* vz); 
   ~lista();
};

class polinom : public lista
{public:
polinom();
~polinom();

};




void lista::afis(nod* vz)
{nod *c=vz;
cout<<"Elementele polinomului"<<endl;
int i=0;
while (c)

 {if (i) cout<<"+";
 cout<<c->coef<<"X^"<<c->grad;
 c=c->adr_urm;
 i++;
 }
 cout<<endl<<endl;
}

nod* lista::adaug(nod *&vf,nod*& sf ,int gr,float cf)
{ nod *c=new nod;
c->coef=cf;
c->grad=gr;
c->adr_urm=0;
if (vf==0) vf=sf=c;
else {sf->adr_urm=c;
      sf=c;}
return vf;
}

lista::lista()
{vf=0;
}

polinom::polinom()
{vf=0;
}

lista::~lista()
{nod *m=vf, *m1=vf->adr_urm;
 while (m1)
       {delete m;
       m=m1;
       m1=m->adr_urm;
       }
 vf=0;
}

polinom::~polinom()
{nod *man=vf, *man1=vf->adr_urm;
 while (man1)
       {delete man;
       man=man1;
       man1=man->adr_urm;
       }
 vf=NULL;
}




int main()
{
int m,nr,nr1;
float n;
nod* vf=0 ;nod *sf;
nod* varFl=0 ;nod *varFv=0;

polinom l,v;

cout<<"Nr de elemente primul pol nr= ";
cin>>nr;
for (int i=1;i<=nr;i++)
{   cout<<"Elementul "<<i<<endl;
    cout<<"Coeficientul = ";
    cin>>n;
    cout<<"Gradul = ";
    cin>>m;
    l.adaug(vf,sf,m,n);
    varFl=vf;
}
l.afis(varFl);

vf=0;

cout<<"Nr de elemente al doilea pol nr= ";
cin>>nr1;
for (int j=1;j<=nr1;j++)
{cout<<"Elementul "<<j<<endl;
cout<<"Coeficientul = ";
cin>>n;
cout<<"Gradul = ";
cin>>m;
v.adaug(vf,sf,m,n);
varFv=vf;
}
v.afis(varFv);

l.~polinom();
v.~polinom();
_getch();


}

Answer 1

Is this a homework question?

For one, your destructor in lista isn't virtual, but a bigger problem is that your destructor in polynom is just a copy-paste of the one in lista.

I think you really need to revise your design and code here...

Answer 2

Your destructors are probably working well, but you call them twice, and the second call probably causes segfaults. Just drop calls like

l.~polinom()

from your code; the destructors are called automatically.

Second thing is, you needn't copy the lista destructor in polinom; the base class' destructor is called automatically, too.

Answer 3

Assuming "polinom" means "polynomial" then you have a basic design flaw - a polynomial is not a linked list. You should be using using containment rather than inheritance to express that a polynomial may be implemented in terms of a linked list.

Answer 4

You ought to have two classes: a monomial class that abstracts a single term with a coefficient and exponent and a polynomial that has a list of monomials as private data member.

The monomial will only allow you to add or subtract terms whose exponents are equal; the result will be a monomial that has that same exponent and the sum or difference of the coefficients. The result from the mul and div methods will also be a monomial that has the product or quotient of coefficients as its coefficient and the sum or different of exponents as its exponent.

The polynomial methods will iterate over its list of monomials to perform the arithmetic operations.

I agree with the comment that discourages you from extending a container like linked list. This is best expressed as a polynomial HAS-A list of monomials rather than IS-A list of monomials. It's a subtle, important difference.

One advantage of HAS-A is that it will allow you to change the data structure you use to store the monomials without affecting clients. Array, list, map - your user doesn't care, as long as you uphold the contract.

I don't know if there's an advantage in treating monomials and polynomials the same, but if there is you'll want an interface defining common methods and a GoF Composite pattern.