Where to declare linked lists

[peaslee]

It appears that if I try to declare a linked list as global (outside of a routine), it doesn't work.

[Paul Turley]

The linked list is a class, and global classes don't currently get constructed.

If you just want to use it from procedural programming then use a global pointer to the list and create it dynamically.

[peaslee]

The linked list is a class, and global classes don't currently get constructed.

You know, I did read that somewhere, but didn't know enough at the time to grasp its meaning. 

I'll rearrange the code a bit.

[peaslee]

This is what I tried:

Code:

class SaleDataDialog cDialog
{
   CPointerList m_SaleList;
   declare SetLinkedList(CPointerList List)
   ...
}

SaleDataDialog::SetLinkedList(CPointerList List) // list is set up in another class instance
{
   m_SaleList = List;
   return;
}

This works to a point. The list data comes through and can be displayed, but when a try to exit the program:

• all the windows close
• the program continues to run in the background
• it consumes about 50% of CPU time

Any ideas?

[Paul Turley]

Use pointers man.  You can't arbitrarily copy once class to another.  Sure it will copy the member variables but the variables are valid only for the class instance that they were created in.  In other words you don't have one linked lists but two when you do that.

So here is how you handle it.

Code:

class SaleDataDialog cDialog
{
   CPointerList *m_pSaleList;
   declare SetLinkedList(CPointerList *List)
   ...
}

SaleDataDialog::SetLinkedList(CPointerList *List) // list is set up in another class instance
{
   m_pSaleList = List;
   return;
}

And then just use the -> operator instead of the .

Paul.

[peaslee]

Thanks. That works.

In general I'm trying to avoid globals so I thought I would just pass the class. It almost worked except the program kept crashing. 

[Paul Turley]

You're welcome.  Just a bit more info. 

When copying a class it acts just like a structure would, copying the contents of each member variable to the new class.  Which is where the problem lies since a member variable might contain a pointer to memory that was allocated for that class instance.  So both class variables end up pointing to the same block of memory.  And when one goes out of scope it might delete that memory leaving the other one hanging.

What we are going to have is a copy constructor soon.  Which allows you to create a special method to handle when a class is copied from another.  Lets say you had a class that allocated memory when it was created, and had a member variable called m_nStatus. The copy constructor might look like this:

CMyClass::Opr_EQ(CMyClass *copy)
{
Create();
m_nStatus = copy->GetStatus();
}

So when you do something like so:

CMyClass cNew;
cNew = cOld;

Instead of just blindly copying the member variables the compiler will check to see if you have a copy constructor first and insert the call:

cNew.Opr_EQ(&cOld);

Have fun,
Paul.

[Parker]

Instead of adding more specific-purpose identifiers like with constructor and destructor, I would prefer to have a new keyword and/or syntax, like "operator =" in C++. It just looks better to me than giving specific identifiers a different purpose in some situations (easter eggs )

[Paul Turley]

Depends on whether or not YACC pukes on it.  Hard enough to get the equal sign to work for both an assignment and boolean operator.

Plus I was just explaining what it does, it wasn't a schematic of anything.

[Parker]

If OPERATOR was a keyword I wouldn't imagine it would have a hard time with it, but I don't know much about how yacc handles things.

(just thinking out loud)
Even if OPERATOR isn't a keyword, when else can you write ID :: ID = ...? It would make sense that it would accept that, but I'm not sure because I haven't used yacc much. Hand written parsers are fun because you can write lots and lots of context-sensitivity into them But then for upcoming operator overloading, OPERATOR should be a keyword anyway so that shouldn't be a problem...