Children inheriting parent variables... But it's denying the variable

[Haley]

i get red lines on the bolded word... but i thought it was ok to have that since the parent class has it..

My "SET" class is derived from "linked list" but i get red lines on the protected variable "front" ... is that suppose to happen?

edit:
you can't actually see it bolded... but it's on line 26 in the for loop

edit:
OMFG ... the order in which you define the classes ACTUALLY matters... DIDN'T KNOW >.>
I had kids before I had parents

edit:
how do i mark this as solved?

[cpp]
// list.cpp
// simple linked list program

#include <STDLIB.H>
#include <STRING>
#include <IOSTREAM>

using std::cout;
using std::cin;
using std::string;

// node object for the linked list
struct Node {
int data;
Node* link;
};

// use inheritance to create a Set class from the LinkedList class
class Set : public LinkedList {

public:
// insert a new value only if it is unique (not already in the set)
void Insert(int newValue) {
bool pass=true;
Node* p;
for (p = [b]front[/b]; p != NULL; p = p->link)
{
if (p->data==newValue)
pass=false;
}

}

// make this the union of two sets
void Union(Set& a, Set& b) {

}

// make this the intersection of two sets
void Intersection(Set& a, Set& b) {

}
};

// implement a singly linked list
class LinkedList {
protected:
Node* front; // pointer to the front of the linked list
Node* back; // pointer to the last node in the linked list

public:
// constructs an empty list
LinkedList() {
front = back = NULL;
}

// deletes the list
~LinkedList() {
// remove objects from the list as long as list is not empty
while(Length() > 0) {
RemoveFront();
}
}

// inserts a node at the front of the list
void InsertFront(int newValue) {
Node* newNode = new Node;
newNode->data = newValue;
if (front == NULL) {
// list must be empty so make front & back point to new node
front = back = newNode;
newNode->link = NULL;
} else {
// list is not empty so insert between front and first node
newNode->link = front;
front = newNode;
}
}

// search the list for a target value
// return index if found or -1 if not found
int Search(int targetVal) {
Node* p;
int count = 0;
for (p = front; p != NULL; p = p->link) {
if (p->data == targetVal) {
return count;
}
count++;
}
return -1;
}

// removes a node from the front of the list
int RemoveFront() {
int returnVal;
Node *temp;
if (front != NULL) {
// list is not empty so remove & return first node
returnVal = front->data;
temp = front;
front = front->link;
} else {
// list is empty just return 0
returnVal = 0;
}
return returnVal;
}

// returns the length of the list
int Length() {
Node* p;
int count = 0;
// loop through each node in the list until we find a null value
for (p = front; p != NULL; p = p->link) {
count++;
}
return count;
}

// outputs a string containing all the data values in the list
void Output() {
Node* p;
// loop through each node in the list until we find a null value
for (p = front; p != NULL; p = p->link) {
cout << p->data << ", ";
}
}
};

void main() {
// instantiate a list
LinkedList list;
int tin;

// insert some values
list.InsertFront(5);
list.InsertFront(4);
list.InsertFront(3);
list.InsertFront(2);
list.InsertFront(1);

// display the list values
list.Output();
cout << "\n\n";
cin >> tin;
}
[/cpp]

[highlight](User was permabanned for this post ("Trolling on an alt" - Craptasket))[/highlight]

[Wyzard]

I'm glad you got it working, but you may want to re-think deriving Set from LinkedList. A set isn't a kind of linked list; it generally doesn't make sense to pass a set where a list is expected. Exposing LinkedList as the base of Set means that users of the class can bypass the set functionality and manipulate the list directly, possibly inserting duplicate items (which is wrong for a set).

If you want to use a LinkedList to hold the items in your Set, it'd be better to make Set contain a LinkedList as a private member.

[Haley]

ok. thanks.
My assignment told me to make it a child though
.But this is great for future reference

edit:
Just to let you see my assignment... here it is
[url]http://f.anyhub.net/24A_[/url]

my teacher said not to do the iLabs. I did do it and it worked... But he said not to do it because it uses the word "set" which is used for setVariablename() which is commonly found with getVariableName()

so I'm assuming there is a general understanding of a "set" class

[gparent]

[QUOTE=Wyzard;28504279]If you want to use a LinkedList to hold the items in your Set, it'd be better to make Set contain a LinkedList as a private member.[/QUOTE]
This is absolutely correct. There's a good chance his teacher doesn't understand is-a relationships (a lot of people don't), but composition is more appropriate for this. Obviously you're still learn about class inheritance while doing the assignment, but keep in mind there can be issues with this approach. Also, there's a void main() in there. Did your teacher write this lab?

Scott Meyers has an excellent example of this in Effective C++, where he shows that deriving Square from Rectangle might make sense at first (A square is a rectangle, right?) but when you dig deeper, it doesn't (you can set a rectangle's height, and it shouldn't affect its width. But doing this on a square makes no sense). His example is more about not associating real-life concepts with inheritance when it doesn't make sense, but it can be applied to this as well.

[Wyzard]

[QUOTE=Haley;28509943]so I'm assuming there is a general understanding of a "set" class[/QUOTE]
Well, a [url=http://en.wikipedia.org/wiki/Set_(mathematics)]set[/url] is a mathematical concept. Its general characteristics are that there's no ordering relationship between the elements in a set (e.g. no notion of one being "before" or "after" another), and no element can be in the same set more than once.

When implemented in software, a Set class typically ignores attempts to add elements that are already in the set (thus preventing duplicates), and when you iterate over the elements, they appear in no particular order (since the order isn't meaningful).

This is completely unrelated to the use of the word "set" as a counterpart to "get". The two meanings don't conflict with each other, because one refers to a data type and the other refers to an action. It's like the difference between a noun and a verb: if I say "I can see a can of tomatoes", you don't get confused by the two meanings of the word "can".

[QUOTE=gparent;28510788]Scott Meyers has an excellent example of this in Effective C++, where he shows that deriving Square from Rectangle might make sense at first (A square is a rectangle, right?) but when you dig deeper, it doesn't (you can set a rectangle's height, and it shouldn't affect its width. But doing this on a square makes no sense). His example is more about not associating real-life concepts with inheritance when it doesn't make sense, but it can be applied to this as well.[/QUOTE]
That's a good point; I hadn't noticed the similarity there. The issue with squares and rectangles is that their relationship is one of restriction (a square is a kind of rectangle with certain constraints) but the relationship between a derived class and its base is one of extension (it's expected to do everything the base class can do, plus potentially more). The relationship between a set and a list (if there's a relationship at all) is also one of restriction, which is why it's not suitable for inheritance.