Hi guys ... Since I like to play the thought that I might be able to program games-related stuff for money some day I'd like to know a bit more about portability of code. I know a lot of people say that it is not important these days ... but I'm guessing there will always be some interesting (game related) jobs that deal with portable code. There's the portability guide by the Mozilla.org browser development team. I'd like to know more about the portability of c++ templates. All the tutorials I found just mention that one 'has to be careful'. Does the Boost library only use portable templates? I think it assumes that compilers respect the ISO standard? I think the STL is not save either ... right? How rare or not are the exotic compilers and architectures that cause portability troubles? What about Linux development on Playstation2 for example? Is modern programming possible or is it closer to writing in C and/or Assembler? Sorry. It might seem as if I'm too lazy to do a research. But those questions came up during one of those ;) Thanks in advance for any jigsaw pieces. Edit: Stooopid me ... guess this would fit better in General Programming. Sorry ...

When talking about portability, you have to tell us about the compilers you are willing to support. The more compilers on your list, the more restricted you become.

(moved to General Programming)

Quote:Does the Boost library only use portable templates?
I think it assumes that compilers respect the ISO standard?

It has a number of workarounds, but a 10-year-old compiler will certainly have trouble.

Quote:I think the STL is not save either ... right?

First, it depends on what you mean by "STL". STLPort is pretty portable. So if your compiler's standard library is deficient you can try and swap it in. In general, you can expect that the library that ships with your compiler will work when used with that compiler. Figuring out if the whole library is there and conformant is up to you.

Quote:How rare or not are the exotic compilers and architectures that cause portability troubles?

Depends on how exotic your platform is. It's the kind of things where if you're on such a platform, you know it, because it means you've become a specialist. [grin]

Quote:What about Linux development on Playstation2 for example?

If it runs Linux, it has GCC. Conformance is pretty good.

Ok. Thanks for the replies.

I did already write games the hackish way and now I want to write reusable (and presentable) code.
I probably started 15 engines so far.
Probably investing time now instead of developing bad habits is the way to go.

The game plan is writing an engine as a static library and keeping it modular.
I want to write it as a 2d engine first, then keep adding features.

I don't want to throw away the whole codebase later. It would be amazing if it
turns out to be portable to all important Mac and Unix Systems.
Maybe I can afford looking into the PS2 Linux kit then.
But I guess I'm simply looking ahead too far.

I am writing own template classes.
But I guess I'll just make sure that there are no warnings on Dev-C++ (with gcc) for now ...
and port to Linux as soon as possible.
Sounds like a plan?

If I want to claim that I'm able to write code for all common Mac and Nix Systems (Unix and Linux) ... are the 10 year old compilers important then?

I hope installing FreeBSD or Debian Linux in addition to WinXP will cut it.
The last time I tried to port code to Linux I failed.
But I think I learned a thing or two in the meantime.

Guess I am just worried of taking the wrong direction now ...

Should I maybe look into writing my own makefiles on WinXP?
Guess my knowledge of build-environments is lacking because I always let Dev-C++ do the work.

What does a programmer (who wants to write portable code) have to know?

Thanks again for all the replies!

Quote:Original post by Clueless
I am writing own template classes.
But I guess I'll just make sure that there are no warnings on Dev-C++ (with gcc) for now ...
and port to Linux as soon as possible.
Sounds like a plan?

Since you're planning to keep the same compiler, you should not only worry about compiling without warnings, but also about which libraries you are using. If you rely on Win32 libraries, you'll have to insulate your code from them before even considering porting it to another platform. I don't believe in using the preprocessor to do that. A better way is to actually have the code specific to each platform in separate files, and have the proper file compiled into the project depending on the platform you're compiling for (e.g. your Win32 makefile would compile foo/win32/network.cpp while the Linux one would compile foo/linux/network.cpp - both of them sharing the same network.h header - these files would each wrap the appropriate network code for each platform, and present a 'portable' interface).

Of course, if you use libraries already designed to be portable, the work already has been done for you - you only have to link your application to the appropriate build of the library. On the other hand, that limits your portability to the set of platforms supported by these libraries.

Quote:If I want to claim that I'm able to write code for all common Mac and Nix Systems (Unix and Linux) ... are the 10 year old compilers important then?

Watch out, you're opening a bigger can of worms than you expect. There are many Unixes. You'll have to find what the equivalent functions and libraries are for each platform. And at any rate, if you can't put your hands on one of those "old compilers" you probably can't be expected to code for them. Making sure that GCC can handle your code is already a good step. For that matter, notice how support for platforms deemed obsolete gets removed from each newer version of GCC (check the release notes). If these platform's users don't care to keep the compiler alive, they're probably not going to be concerned about your application running on their system.

Quote:I hope installing FreeBSD or Debian Linux in addition to WinXP will cut it.

Fair enough.

Quote:Should I maybe look into writing my own makefiles on WinXP?
Guess my knowledge of build-environments is lacking because I always let Dev-C++ do the work.

What does a programmer (who wants to write portable code) have to know?

automake/autoconf are a horrible mess, but I guess they are part of the things you would have to know if you wanted to write portable code (across the various *nixes) ... I know I haven't bothered with it.

Quote:Since you're planning to keep the same compiler, you should not only worry about compiling without warnings, but also about which libraries you are using. If you rely on Win32 libraries, you'll have to insulate your code from them before even considering porting it to another platform.

Yeah. Until now I have worked with conditional compilation to have the option to add new operating system specific code.



The window class CWindow is abstract for example.
But I thought i'd derive classes like CWinWindow from that class.

You are probably right ... that is a bad idea.
Looking into the build environment options for the codebase is probably what I should do.

I'll take a close look at how Quake2 does it.
And there are some other interesting open source libraries ...
I think I know what I should look for now.

Thanks again :)

Quote:Original post by MaulingMonkey

Quote:What about Linux developmention Playstation2 for example?
Is modern programming possible or is it closer to writing in C and/or Assembler?

No personal experience here, you'll have at least C, and AFAIK you'll probably have C++, although prehaps not all the SC++L depending on compiler, and due to special preformance considerations your company may shun the SC++L anyways (even though custom allocators may be a better solution).

I have developed for the PS2, and we used gcc3.x, which worked great for STL and simple template stuff. The project had long been developed using gcc2.9x so that prevented us to use STL from the start, but for newer projects templates and STL should not be an issue.

The only issue on the PS2 is memory, but templates doesn't add to that, but some STL classes are bloated so that might be a concern though...

I think the question about portability has been addressed pretty well so I won't go into that. I did want to answer your question about makefiles. I'd recommend using the same solution on all platforms, so either make or scons or something similar. I'd recommend SCons as it has built in autoconf-like ability and is much easier to use IMO than make.