Moving constants to simconst.h

[gerw]

I'm currently cleaning up the header files. I replace includes of other header files with forward declarations in order to reduce compilation time.

Now simcity.h defines MAX_CITY_HISTORY, so we have to include it in gui/stadt_info.h, e.g. I think, it's more consistent to put such constants into simconst.h. Otherwise, everytime simcity.h is changed, we have to compile gui/stadt_info.cc, even if the constant isn't changed. Much more constants can be found in simconvoi.h, simhalt.h and simline.h.

What's your opinion?

[VS]

If you create just one constant header/container file, will change in it require recompilation of everything or not? If yes, try to group constants together, but in reasonable packages(buildings, factories, vehicles, lines...). But there might be some dirty tricks you know, so take that with a grain of salt.

[gerw]

If you change simconst.h, everything, which includes simconst.h (this is almost everything), is recompiled. But you won't change simconst.h very often. Currently the constants are spread over several header files and if you change one, almost everything is recompiled.

The most evil header file is simwerkz.h, since it includes a bunch of other headers and it's included in most other headers.

[prissi]

In this case I am not sure, if I want to change the location. Putting it into simcity.h (where the history actually is) is C++ style. A central header file is very C-style.

Also this is due to a braindead make system. MS manages with MSVC to recompile only the parts that actually use the changed lines and not the ones that only use the uncahnded lines.

Imho, this is a clear case where readability conflicts with compile speed on Linux. My feeling is, to keep it OO and thus in the header of the city.

[gerw]

Here are my header cleanups. I only moved some functions from grund.h to grund.cc, elsewhere I didn't touched anything except the includes.

Maybe we could move some of the functions defined in simwerkz.h to simwerkz.cc in order to save some inclusion there.

[prissi]

But putting the functions inside grund.cc means that those cannot be called inline. I think this may have some impact on route searching and related tasks.

[gerw]

But they aren't defined as inline. Are they inlined automatically?

[prissi]

That depends. But not defined in the header will make them non-inlinded in GCC (althoug I do not know about version 4). Of course in principle the could be still inlined, but usually they are not. If the profiling shows them, there id a good chance it is not inlined.

The profiling on GCC 3 shows get_weg has even 1.25% of the total consumption, which is quite much. Maybe explicitely using inline keyword can help here.

But I think only profiling will bring a correct answer.

[gerw]

Ok. So we can just let them in grund.h.

[gerw]

I pushed bach these lines into boden/grund.h. New patch attached.