I have heard something like there can only be 64k of global variables, which makes sense. Now I have kind of run into a design problem. I currently have a class that holds a mesh (.x file) and the required variables for it, which is global. That way I just create a new global variable for each mesh that I load in. This doesn''t seem like a good idea because I am afraid I will overrun the 64k for globals. How is it possible to have other classes have access to a class without it being global? I mean I have several member functions of various classes (for input, lighting, transformations, etc) that need access to the mesh. How can this be done without too many global variables? I hope that made sense...

You can just make a global pointer, then alocate memory for the class, that way the only "global" variable is the pointer, but it can access the class, which is in the heap.
See code below.


global

CYourClass *stuff;


int main() or WinMain()
{
stuff = new(CYourClass);
.
.
.
}

int EndProgram()
{
delete(stuff);
}



Jason Mickela
ICQ : 873518
E-Mail: jmickela@pacbell.net
------------------------------
"Evil attacks from all sides
but the greatest evil attacks
from within." Me
------------------------------

Actually, the 64k of global variables only applies to DOS, and is then dependant on which memory model you use to compile your program with.

Under Win32, each process has its own 32-bit virtual address space of up to 4gb (although 2gb is reserved for the kernel).

I bring this up since you mentioned .x files, and thus assume you''re writing for Win32/DirectX.

As griffenjam suggested, use pointers. That way you don''t have to pass your whole freakin'' class onto the stack, which is S-L-O-W.

It''s fun pretending you know stuff

-Rabid

What considerations are there for abnormal program termination? Are these global variables still present afterward, causing a memory leak? Granted, this isn''t as much an issue on a Linux/Unix system. Would adding either C, C++, or SEH exception handling (particularly a hybrid of C and C++ exceptions) offer an alternative to the potentional leak without too much overhead? I''ve seen an encapsulation which involved using a function before the instance was declared and, though I understand how and why it works, doesn''t seem to be a clean and concise programming method. What would be some suggestions in this case? Specifically an example for the moment on a Windows platform, but also examples on others such as Linux.

I don''t think abnormal program termination causes a memory leak. When the program is terminated, your OS will take over, and free the memory used by the terminated program. Not sure, though...

Global variables can''t make memory leaks, because they are allocated at the start of program and deallocated at the end. Variables on the stack as well. Memory leaks are caused by resources allocated while program is running and not deallocated anymore (objects on the heap, opened files, mutexes...).

To avoid memory (and other resources) leaks you have to take care of two things:
1. Dealocation routines, which release all your alocated resources (in C++ destructors...).
2. Calling of these dealocation routines, when alocated resources aren''t needed anymore.

Exception handling performs the second task. First task you must do on your own (in case of heap resources you can use library smart pointers - my preferred choise - or some garbage collection system, which also does the second task).

Differences between platforms (Win32,Linux) depend on diffences of allocated resources on these platforms. In case of memory resources these platforms are practically identical (if you use the library working on all platforms - STL maybe).

Actually, I''ve heard that there used to be a bug in the older Win 9X codebase (i.e. Win95) where, in some cases, the OS would not clear the heap properly, and you''d end up with memory leaks if you run the same program many times. If you''re using a newer OS (Win NT/2000 especially) this isn''t really an issue. Still, it''s bad practice to leave anything on the heap anyway.

I could be wrong about that bug, but it does sound like something Windows would do

Anyway, if you write destructors properly and handle errors and exceptions right, you won''t run into any problems.

So how do professional games handle things like this? Do they use the pointer method and keep track of all the meshes to be loaded in an array or something?

The avoidance of global variables doesn''t have anything to do with the physical performance. There''s no physical difference between a global variable and one that''s encapsualted by a class, even if it''s pointed to by a global pointer. The reason you want to avoid globals is because the global namespace should be kept as clear as possible to avoid naming conflicts. Global variables pollute the global namespace, and make it hard to integrate things into your project (or vice versa).

Dean_harding is correct about Windows leaking memory from apps. I didn''t believe it myself, so I wrote a program that blindly leaked tons of memory (many megs worth). According to the task manager, that memory was never released. No program should leak memory anyway, even if it fails (good exception handling = professional code), but this is even more cause to be careful.

How do you pass values to WndProc without the use of globals? Whenever I use globals I put them in a global structure to avoid namespace conflicts.