Skip to main content ↑ ↓
Topic: What platforms does Simutrans actually need to compile on? (Read 5795 times) previous topic - next topic

What platforms does Simutrans actually need to compile on?

 ???

I'm trying to get a sense of what I can expect from the compiler and standard C++ libraries (since I've been wondering why some of the standard library features aren't used).  I know that GCC 4.x under Linux is important.  Current and even somewhat obsolete versions of Mingw also use GCC 4.x, and the same with FreeBSD, so I don't need to worry much about them.  The Mac appears to use GCC 3.1 or later, or GCC 4.x.  Cygwin uses GCC 3.4 or later.

I also know that MSVC++ is important under Windows -- but what versions?

BeOS and older versions of Haiku use gcc 2.95, which is absurdly obsolete; is anyone actually still using this, and does it actually work?  If not, perhaps Simutrans could drop BeOS support and leave only Haiku-with-gcc-4.

Most of the features I'm thinking of were present by GCC 3.1, all were present by GCC 3.4, and I'm pretty sure they're in recent versions of MSVC++ as well.

Re: What platforms does Simutrans actually need to compile on?

Reply #1 –
for the nightlys I use (Just for information)

Linux:
32Bit: gcc 3.4.6 und 4.1.2
64Bit: gcc 4.3.4

Windows:
32Bit: gcc 3.4.6

Mac:
Intel:      4.0.1
PowerPC: 4.0.1

For the Moment there is no projekt for compiling nightlys for windows 64 Bit, because 32 Bit Software run without a Problem.
When I use a newer gcc for Windows simutrans get Problems with sdl
I hope you understand my English

Re: What platforms does Simutrans actually need to compile on?

Reply #2 –
Simutrans compiles on GCC 2.95 nicely, on the native BeOS CC too, and on MSVC beyond version 6. It should compile on any compiler which is C99 compliant. I never tried watcom, but I suspect it working there too.

Do not forget: Simutrans started in 1997, thus STL is newer than simutrans. And some of the templates in simutrans are easier to use and/or more optimized than STL templates (which are optimized for general use).

Thus: stay away from features only GCC supports. Avoid to much STL, and rather use the simutrans templates. Or convert everything to C99 STL-like notations. Nothing newer than C99 or it will greatly impact portability (whichout any gain.)

Re: What platforms does Simutrans actually need to compile on?

Reply #3 –
Quote from: prissi – on
Simutrans compiles on GCC 2.95 nicely, on the native BeOS CC too, and on MSVC beyond version 6. It should compile on any compiler which is C99 compliant. I never tried watcom, but I suspect it working there too.

Do not forget: Simutrans started in 1997, thus STL is newer than simutrans. And some of the templates in simutrans are easier to use and/or more optimized than STL templates (which are optimized for general use).

Thus: stay away from features only GCC supports. Avoid to much STL, and rather use the simutrans templates. Or convert everything to C99 STL-like notations. Nothing newer than C99 or it will greatly impact portability (whichout any gain.)

Hmm.  I was thinking of the C++ '98 standard, which includes large portions of the STL.  Except that the implementation of some of the STL containers in gcc 2.95 (and some other compilers of the period) is buggy, so one wouldn't want to use most of the STL if compiling under gcc 2.95.  Under more recent compilers stuff like <vector> is probably implemented faster than any hand-written design could be (inline ****embly language etc.), but not under older compilers.  Some of the simutrans templates are clearly optimized for simutrans use anyway, of course.

However, what I was really thinking of is <string>.  C-style string handling requires a *lot* of bounds checks, and to be blunt most of them are missing in simutrans.

Re: What platforms does Simutrans actually need to compile on?

Reply #4 –
Do not use char[] for vairable strings then, use the cbuffer_t cl****. This is there exactly for this reason. Or, if the maximum length is not known, then use cstring_t (which is much slower). C string handling is fine, when you are sure of the length of certain structures. (An unit32 printed as a number is always shorter than 12 bytes, no matter what number size.) Handling user input is of course something completely different.

STL is not there on all plattforms and was not there during most of the time simutrans was programmed. The few uses of STL were added in 2008, and I was not very fond of getting two template systems next too each other. But those added, worked on all supported plattforms.

By the way vector cannot be implemented faster but the STL compared to a standard template. Boundary check and access are so elemental operations that any compiler should generate the same code. templates are only generated during compile time since type size and initializers/overloaded functions/destructors are type depended. I fail to see how STL could use handoptimized ****embler. This is a myth.

General lists (which work on all plattforms) in STL were slower than simutrans, since the standard ones comes with two pointers per element. I did profiling.

===================================================

If one start simutrans todays, one would of course use STL, gettext and all the other tools not there 13 years ago. One would even use JAVA and not C++ I think.

But instead converting simutrans to STL I would rather focus on more useful stuff for the user. Even more, the simutrans way of templates are much easier to understand to non OOP specialists like me back then.
 

Re: What platforms does Simutrans actually need to compile on?

Reply #5 –
Quote from: prissi – on
Do not use char[] for vairable strings then, use the cbuffer_t cl****. This is there exactly for this reason.
OK, thanks.  :-)

Quote
By the way vector cannot be implemented faster but the STL compared to a standard template. Boundary check and access are so elemental operations that any compiler should generate the same code. templates are only generated during compile time since type size and initializers/overloaded functions/destructors are type depended. I fail to see how STL could use handoptimized ****embler. This is a myth.

Oops.  I just realized that simutrans is single-threaded.... I've been doing multithreaded programs just long enough that I forgot that the hand-optimized ****embler I was thinking of was the code for thread safety.  Yes, the single-threaded code is going to be generated the same by any compiler.