Most of boost can be swapped for C++11/14

[ensiform]

Most of the boost usage can be removed in favor or C++11 / C++14. MSVC 2013 and 2015 should support everything needed. FS obviously needs to stay (IDK about ENABLE_DOWLOAD stuff) and/or interprocess if that is still being used, dynamic_bitset seems to be the only thing not replaceable.

Probably don't need for interface code at all.

boost::shared_array can be a unique_ptr<char[]>

hash_map has long since been deprecated, unordered_map<> is the preferred container.

[plastovicka]

Most dedicated game servers run on Linux. We have already tried to use newer version of gcc. Some administrators immediately responded that they could not start the game because of missing GLIBC or LIBSTDC++. We had to revert and return to old version of gcc.
RTCW and Enemy Territory are very old games. Some servers are running for years and admins do not want to update system libraries.

[ensiform]

Hmm, I see? We're forcing the hand with C++11 for OpenJK now which is for Jedi Academy. Just how old of software are these servers running... Not to mention, why? Are they servers that see lots of players to matter too?

Maybe we could have a switch when moving to CMake that allows avoiding boost as much as possible?

[plastovicka]

Do you really want to use Omni-bot in Jedi Academy ? I think it would be very hard to convert Omni-bot interface and goal scripts.

[jswigart]

We had Omnibot working in Jedi Academy years ago and using some of the
force powers. But I think he's talking about the mod itself. Linux has the
issue that it is more invasive to update the libraries than it is in
Windows. For Windows you just have to install the 2013 or whatever
redistributables. For whatever reason it's not as easy I guess in Linux.

The advanced stuff I'm doing in the main bot branch is using some more of
modern c++. I'm using thread, regex, and file system stuff that's not in
std. I've already converted to unordered map and a few other things.

On Fri, Oct 23, 2015, 7:14 AM Petr Laštovička [email protected]
wrote:

Do you really want to use Omni-bot in Jedi Academy ? I think it would be
very hard to convert Omni-bot interface and goal scripts.

—
Reply to this email directly or view it on GitHub
#7 (comment).

[plastovicka]

I didn't know that Omni-bot is working in Jedi Academy. Could you write some info on the wiki ?
http://omni-bot.invisionzone.com/wiki/index.php?title=Supported_Games

[jswigart]

We never released anything yet so it didn't seem right to advertise it.

On Fri, Oct 23, 2015, 9:48 AM Petr Laštovička [email protected]
wrote:

I didn't know that Omni-bot is working in Jedi Academy. Could you write
some info on the wiki ?
http://omni-bot.invisionzone.com/wiki/index.php?title=Supported_Games

—
Reply to this email directly or view it on GitHub
#7 (comment).

[ensiform]

Regex actually is in C++11, but I tried swapping out std::hash_map for std::unordered_map and it fails on GameEntity object.

Also, Jedi Academy using newer C++ doesn't change things for OB. I was just trying to avoid using boost with VS 2015.

JA support was only for my old mod at one time. It would need to be re-added to an OpenJK fork at some point.

I got the 0.83 JA dll compiling under 2015 now with boost (1.59.0). It found a lot of variable shadowing also.

CTF and siege would be ideal starting points but I'm no good at creating goal code or scripts. I could start another issue with JA support ideas/needs with a todo list if you want.

[adanski]

Most dedicated game servers run on Linux. We have already tried to use newer version of gcc. Some administrators immediately responded that they could not start the game because of missing GLIBC or LIBSTDC++. We had to revert and return to old version of gcc.
RTCW and Enemy Territory are very old games. Some servers are running for years and admins do not want to update system libraries.

Come on, even all the time outdated Debian (if we talk about packages) has gcc 4.9 already: https://packages.debian.org/pl/stable/gcc

There's no point in "supporting" unsecure servers that use ancient OSes.

[jswigart]

I agree to large extent. There's only so much I'm willing to be held back by the limitations of particular deployment environments. I'm not sure why static linking isn't more of a solution to these dependencies on Linux as it is with Windows.

[ensiform]

Because security is higher priority than static linkage. And static linkage does not allow for security patches without manually updating every package that is used by your product and recompiling them + your product.

[jswigart]

That's great in theory. But as we see the added pita of all the interdependencies ends up meaning lots of users don't bother to update at all. I see this same issue in commercial environments. It's an OS enforced "dll hell" that most people don't bother keeping up with.

[wallabra]

A summary of the stakes at hand here; Boost is an extra dependency, but including it means maintaining compatibility with less recent compilers (of the likes of those used in most id Tech 3-related software back in the day).

On the other hand, forcing developers and people building the project to newer compilers might be dangerous if they want to build with it an older project, like for a simple example an older game or game-specific library that contains compiler-specific features or syntax, or simply has a target that most modern compilers wouldn't support (like Little C Compiler's bytecode format, used in Quake 3 Arena and I think other id Tech 3 games as well).