Winboard Forum

I am planning to get rid of my global varaibles and have structure similiar to fruit when variables that are used in some files are included only in part of the files.

The problem is that global variable appears in more than one file and
I am not sure of how to divide the variables to files

I think that the first step will be simply to write note for every variable and every function in which jobs they are used in order to design how exactly to divide the programs to files(I use the word job and not files because I may divide some of my long files to more files and one of the reason that I did not do it until today is speed because I found that including all the global variables in more files is more expensive and having seperate file for the qsearch that include all the global variables made movei slower so alphabeta together with the qsearch and more functions like sorting moves is in the same file today)

I wonder if people have experience in getting rid of global variables.

Uri

Create a map file with your compiler.
That will give you a list of the global variables.

Consider them one at a time, and ask yourself for each variable:
Which functions REALLY need access to this? It is quite important to limit it to the bare minimum.

When you do complete the list of things that really have to be global, collect them into structures or classes of similar functionaltiy (if you have not already done so).

Then consider carefully the best way to access them. You never have to worry about reads of global variables if you do everything else right.

It is new/delete or malloc/free and updates that must be very carefully scrutinized.

You are a very smart fellow and I expect that you will solve the situation very nicely.

Global variables are not an invention of the devil. C++ encounters the possibility to establish namespaces, where an implementation as static variables of a class would not be natural.

Reinhard.

Global variables are often a necessary evil.
In C++ cin and cout are global variables.
In C, stdin and stdout are global variables.
It would be difficult to write programs without any global variables.

However, when you want to write an SMP program, global variables are evil incarnate.

It doesn't bother me to have global variables if I know they are constant and that I will never need more than one instance of them.

For example the attacktables used for rotated bitboards and the evaluation parameters are global variables in my engine.

I don't think there is much reason to wrap these in namespaces or classes, it would just require a lot of additional keypresses typing new code.

If C++ had the ability to do "read only" inheritance of variables there would be a point, but such a thing doesn't exist in C++.

-S.

When I started writing my new program I didn't really care about global variables. It is going to be SMP, but use processes instead of threads. Threads were just too messy for me, and I got tired of having BOARD *board as the first parameter to almost every function.

As for splitting the global variables into different files, the only reason I see to do that is for clarity. In my experience it produces the fastest code to just #include all of the C-files in one, and compile that, which makes the location of all the variables file-wise meaningless.

Regards,
Zach

Zach wrote:... it produces the fastest code to just #include all of the C-files in one ...

If you want to compile foreign code this might help.
If you want to reorganize and improve your own thoughts, I doubt.

Reinhard.

No, I don't compile foreign code. I am not reorganizing either. Do you know what "#include" means?

Zach Wegner wrote:As for splitting the global variables into different files, the only reason I see to do that is for clarity. In my experience it produces the fastest code to just #include all of the C-files in one, and compile that, which makes the location of all the variables file-wise meaningless.

Regards,
Zach

I tried that too. I couldn't spot any speed improvement but it does save some kB off the final exe.

My guess is that the linker can't figure out how to completely remove all the redundant stuff in the object files.

-S

Come to think of it, I use VC7 with global optimizations enabled.

There might be a speed gain with e.g. VC6 which, IIRC, doesn't have global optimizations(?)

-S.

Sune Fischer wrote:My guess is that the linker can't figure out how to completely remove all the redundant stuff in the object files.

Very likely. Neither should it make much difference. Perhaps the engine has some megabytes of dead code and data. What will happen. At first, the OS may load all of this, and reserve all the memory of it. When RAM gets tight, anything unuses will get swapped out. And totally dead code will of course never be accessed again.

Of course, this is a bit over simplified. But practically, it won't matter at all.

A similar situation: My engine includes a lot of book generation code, PGN utilities, ... . This is not really dead code, but in normal games, this code will never be accessed. I bet, that you won't see a difference, when I really throw out that code (and lots of data space, that is only needed by this code). The very careful user may see, that his favorite toll shows lots of memory consumption (muh more, than he expected). It won't make a difference, however.

Regards,
Dieter

Reinhard Scharnagl wrote:Global variables are not an invention of the devil. C++ encounters the possibility to establish namespaces, where an implementation as static variables of a class would not be natural.

Reinhard.

I think that even without classes it is better that variables that are not used in some files will not be global relative to these files.

Movei has a files data.h that includes all the global variables and every C file includes data.h(I learned this structure from tscp).

When I say "getting rid of global variables" I do not mean no variables that are global relative to part of the files but no variables that are global relative to all files.

Uri