#3 Uninline Simparr array and string class methods

[Kimmo Varis]

Frhed/Simparr.h and Simparr.cpp define custom array and string classes. Many methods are defined inlined in header file. There are many (most of them?) methods inlined that simply make no sense to inline.

It simple makes no sense to inline e.g. those over 20 lines long InsertAtGrow() methods.

So I'm moving most (maybe all?) currently inlined method implementations to implementation (.cpp) file. In case somebody can point out this makes Frhed slower, then we can think of inlining some selected methods.

And do we really needs these custom array and string classes? Why not simply use STL classes?

[Jochen Tucht]

Logged In: YES
user_id=766060
Originator: NO

Please remove the inline keyword from Simparr.h. It was an attempt to fix linker errors which, as it turned out, had been occuring for other reasons.

Moving template functions to implementation file won't work for many popular compilers because it requires template expansion to be deferred to link time.

I have no ambitions to convert code to STL, but I have no objections against anybody else doing it either.

[Kimmo Varis]

Ok, I uninlined the implementation methods and moved them to new file (Simparr_imp.h) which is included to the Simparr.h. This way the main include file (Simparr.h) remains clean (and easy to read).

Completed: At revision: 102