Migrate to the C++ Standard Library

[koraa]

Internally sauer uses lots of self-implemented types; these types are implemented in headers, which slows down compilation and makes it harder for new devs to get started.

• Investigate what can be refactored
• Document
• Apply!

[a-teammate]

i've my concerns about using the stdlibs.. thou it is true that new devs will have to look around in the code first and have to adapt to this style compilation speed is not really influenced by such. furthermore the code itself is faster and smaller this way. i dont see the point in wasting time redoing stuff which is actually pretty awesome just for the sake of making the environment the same as you used to have it in other projects..

thou im open to switch my mind, so maybe if you can give some good examples why it should be rewritten..

[koraa]

"code itself is faster and smaller this way" – would you please explain that?

Personally I don't really see any gain in keeping Sauerbratens own libs: More code means more work to maintain it; if we use libs we get that work for free. If we decide against libs (or for writing our own), we should be sure, that we are better at coding, testing, debugging and reviewing the code than the creators of the lib in question.

As for my self I think that I am much worse suited for the task of implementing a standard lib than the creators of the compilers we use…

[a-teammate]

Maybe im mistaken in this point but if you want to add a function for example to something standart, you have to write your own one again. Plus you are using a lot of overhead you do not really need. This makes the functions bigger and overall this will have a long rat-tail.

Furthermore i do not see your issue, Sauerbraten is written in a C-ish C++, so this basicly means rewriting a whole game (Making any vec2 a Vector2, any string a std::string,.. :) Beeing afraid of errors should lead to more carefullness not to more core-changes ;)

I think we can find and solve more pressing issues. But maybe when you create patches which are written with stdlibs, we can afterwards all together translate them into a sauerbraten-alike coding style if you want :)

[Fohlen]

Just to be mentioned, char[256] is NOT a string. Making thing's more standard compliant would mean making stuff easier for us and commitment in the future. Though I agree with @a-teammate that this is huge task, which basically mean's rewriting the whole engine. Maybe we can write transponders to "translate" between eihrul-ish standard-lib (string, vector...) and the normal c++ lib by overloading the string with a char (constructor) As a result we would get a standard-compliant string which can be used for further programming as well as supporting the "old" strings, so we won't break the engine.

[IAmNotHanni]

Keeping Sauerbratens standard libraries, templates and classes garants us the total incompatiblity with other code parts that require the C++ standard libraries.

[N0Wire]

@Fohlen: char[260] is a string, it is a C-String. The main problem of the sauerbraten code is the mix of C and C++ (as @a-teammate said). Not only "sauerbraten-string" is interferring with the standard-lib. Also the implementation of vector and new & delete from scratch are big problems we have to face. The new & delete issue can be easily fixed. Just remove those few lines. The way of the implementation should be compatible with the C++ standard-libs. The Vector - class can't be adapted, because eiruhl added some functions like inrange and add, which vector of C++ doesn't contain. So we can't come arround with rewriting the engine. ( But it doesn't make more efforts than we have to put in the string-problem!)

My intention is to use "find and replace" in an efficient way. (We have to write a small tool for it!) For expample replace every 'copystring(name, "Name");' with the following schema 'name = "Name"' (name is a std::string here!) The tool should work with search-template and rules (you can define yourself) and so on.

[koraa]

Please refer to the karo/stdlib branch; some things are already done.

As for the search replace tool…I used sed and compiler errors…

[N0Wire]

Mh, i found an easier solution (quick and dirty): use find and replace for every file and replace string with sbstring and vector with sbvector. Finally just remove the new & delete implementation and it will work. So you don't need to modify much and you can use the C++-standard-libs without any doubts ;).

[koraa]

This is not a very pressing issue, so I would like to do this cleanly, by removing all the redundant code. This means quite a lot of refactoring, but I think it is possible to do this bit by bit.

Your suggestion would certainly work, but I think it would not Improve the situation so much.

I suggest that if we find a lib that is actually blocked by the non-standard lib we can apply your solution as a (permanent) temporary fix.

[Fohlen]

I think @N0Wire 's quickndirty solution is an interesting temporary fix. Some could go and "outsource" the existing sauerbraten library (eg: libsauerstd) so stuff could be resolved by simply using namespaces. This would give the advantage to minimize our effort's as well as it would support ANY code developed with the existing engine.

[a-teammate]

The thing with temporary fixes is that they have the tendency not to become remade again afterwards... So i agree with koraa, this should be done carefully and cleanly.

[Fohlen]

@a-teammate thus I think the idea of outsourcing the existing standard library to libsauerstd, resolving errors with namespaces would be a good concept.

[aschaeffer]

You mean a transitional library to remain compatible until everything is migrated?

[Fohlen]

I mean taking all of that existing "standard lib" to one library (libsauerstd) so it can be outsourced easily. Engine part's depending on the old standard can use this library, and we could use standard-compliant tools in any further development.

[Fohlen]

We decided that new implementation to the re-worked sauer can only support standard C++11 or newer. Closing this.