# About portability e.g. of templates

## Recommended Posts

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 ...

#### Share this post

##### Share on other sites
Quote:
 Original post by CluelessThere'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'.

This is due to the glut of aging non-conforming compilers out there. AFAIK, the newest versions of both Microsoft's and the GNU organization's compilers both implement the semantics correctly.

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

There's no such thing as portable templates if you're talking about including compilers like VC6 - they make ample use of workarounds to get things running on other compilers (so no, they don't assume ISO C++, but that's their main target). If you peek at their sources, you'll see a lot of #defines and #ifdefs and so forth (depends on the library). Not all boost libraries can be used on all C++ compilers, although they do try to make them as portable as possible.

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

Yes and no. Most compilers are consistant when it comes to USING template classes.. e.g.:

std::vector< int > pie;

Is safe. Compilers are less consitant when it comes to writing template classes.

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

Lots of people are stuck using VS6 as their devlopment platform, which can cause plenty of portablity issues (it's template support is horrid). People still use GCC 2.95 for some reason too.

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).

True portability, in the sense that the code will be able to work out of the box, can be a pain in the ass to accomplish. Chances are, however, if you need to switch compilers, the ride won't be too tough, as long as you arn't writing pages of meta-magic using things like boost::mpl.

#### Share this post

##### Share on other sites
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.

#### Share this post

##### Share on other sites
I recently ran into a C++ Template problem which only is avail in VC7.0 where as VC6 didn't quite support the standard for templates. I wish I could remember what it was and relate it to you, it stumped me for a few days, ended up upgrading to VC7.0

Portability is very important, but not to other systems. For game development, aim the game for the system you wish to run it on. BUT, make sure you write it smart so you could easily modify the rendering routines for example for work on a Linux Gfx Lib. A few preprecessor #if.. and a smart programmer.

Another one is Wide-char vs ANSI standard.
Our 26-letter alphabet, or the 255 ASCII standard use's 1 byte per letter.
Most all other countries around the world use Wide-char which is 1-4 bytes.

If you plan to make games, you will eventually have to learn how make them portable into other languages.

There is lots of detail.

But if you are just starting, then you should just start making games :) Worry about portability when the problem arrise's.

#### Share this post

##### Share on other sites
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!

#### Share this post

##### Share on other sites
Quote:
 Original post by CluelessI 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.

#### Share this post

##### Share on other sites
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.

// Defines#if defined(WIN32)||defined(_WIN32)||defined(__WIN32__)    #define DD_WIN#elif defined(CYGWIN)|| defined(_CYGWIN)||defined(__CYGWIN__)    #define DD_CYGWIN#elif defined(unix)||defined(__unix)||defined(_XOPEN_SOURCE)||defined(_POSIX_SOURCE)||defined(sun)||defined(__sun)||defined(__FreeBSD__)||defined(__NetBSD__)||defined(__OpenBSD__)    #define DD_UNIX#elif defined(linux)||defined(__linux)||defined(__linux__)    #define DD_LIN#elif defined(macintosh)||defined(__APPLE__)||defined(__APPLE_CC__)    #define DD_MAC#else    #error "Sorry. Platform not supported!"#endif// Includes#ifdef DD_WIN    #include "platform/ddwin.h"#elif defined(DD_CYGWIN)    // #include "platform/ddcygwin.h"    #error "Sorry. Cygwin not supported"#elif defined(DD_UNIX)    // #include "platform/ddunix.h"    #error "Sorry. Unix not supported"#elif defined(DD_LIN)    // #include "platform/ddlin.h"    #error "Sorry. Linux not supported"#elif defined(DD_MAC)    // #include "platform/ddmac.h"    #error "Sorry. Mac not supported"#endif

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 :)

#### Share this post

##### Share on other sites
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...

#### Share this post

##### Share on other sites
Quote:
 Original post by gulgiThe 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...

One problem that many OOP-purists have with the STL is its method bloat. In particular, they point to the large number of functions in std::basic_string which would be better implemented as non-member functions. But this sort of bloat doesn't do anything to the memory usage. Other than that, do you have any actual examples of bloat within the STL?

#### Share this post

##### Share on other sites
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.

#### Share this post

##### Share on other sites
Quote:
Original post by Sneftel
Quote:
 Original post by gulgiThe 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...

One problem that many OOP-purists have with the STL is its method bloat. In particular, they point to the large number of functions in std::basic_string which would be better implemented as non-member functions. But this sort of bloat doesn't do anything to the memory usage. Other than that, do you have any actual examples of bloat within the STL?

std::string is the best example.. ;] .. and yes, those functions do take up memory as well (they need memory to reside in as well). Maby with a better linker... ah well.

On the PS2, every byte counts, I even had to write a defrag function for the texture-handler, else the game would have died after a while...

It is nice to write games for the PC again. Oh the amount of memory! :D

## Create an account or sign in to comment

You need to be a member in order to leave a comment

## Create an account

Sign up for a new account in our community. It's easy!

Register a new account

## Sign in

Already have an account? Sign in here.

Sign In Now

• ### Forum Statistics

• Total Topics
628278
• Total Posts
2981785

• 10
• 11
• 17
• 13
• 9