Thread: Looking for info: Cross-Platform

  1. #1
    Registered User
    Join Date
    Feb 2006
    Posts
    21

    Looking for info: Cross-Platform

    Hey, im looking for more info into making libraries cross-platform, examples would be nice, descriptions, links anything you can provide. My google searches always come up with a mass-list of other people's cross-platform libraries, and no info on actually making them cross-platform.

    For info: Im working on a simple console library, change colors etc and it currently supports both win32 and unix via a collection of preprocessor includes..

    Code:
    #if defined _WIN32
    
    // code here
    
    #elif defined __unix
    
    //code here
    
    #endif
    Is this the method that other people use when designining and creating cross-platform libraries, or is this just the nub method of doing it?

    Any info would be great. Thanks.

  2. #2
    Registered User NeonBlack's Avatar
    Join Date
    Nov 2007
    Posts
    431
    You'll want to use standard code as much as you can, but where this is not possible, yes this is generally how you use nonportable code in a cross platform manner.
    I copied it from the last program in which I passed a parameter, which would have been pre-1989 I guess. - esbo

  3. #3
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,659
    Something like this:

    Code:
    // screen.h
    #ifdef SCREEN_H_INCLUDED
    #define SCREEN_H_INCLUDED
    
    typedef struct screen_obj screenObj;
    
    screenObj *myScreenInit( void );
    void myScreenClear ( screenObj *s );
    
    #endif
    Code:
    // screen_win32.c
    #include "screen.h"
    #include <windows.h>
    struct screen_obj {
      int   a;
    };
    
    screenObj *myScreenInit( void ) {
      screenObj *s = malloc( sizeof(*s) );
      s->a = 42;
      return s;
    }
    
    void myScreenClear( screenObj *s ) {
      printf("%d\n", s->a );
    }
    Code:
    // screen_linux.c
    #include "screen.h"
    #include <ncurses,h>
    struct screen_obj {
      char *p;
    };
    
    screenObj *myScreenInit( void ) {
      screenObj *s = malloc( sizeof(*s) );
      s->p = "hello";
      return s;
    }
    
    void myScreenClear( screenObj *s ) {
      printf("%s\n", s->a );
    }

    Code:
    // main.c
    #include "screen.h"
    int main ( ) {
      screenObj *s = myScreenInit();
      myScreenClear(s);
      return 0;
    }
    Now the real magic is:
    For a win32 project, you compile main.c and screen_win32.c
    For a Linux project, you compile main.c and screen_linux.c

    Porting to another platform, you just write a new screen_xxx.c file.

    main.c at that point couldn't give a hoot.

    Notice in the header file, the screen is declared as an incomplete type. This means that all main can ever do is maintain a pointer and never dereference it.

    Also note that inside each implementation file, the struct is declared to be whatever we need it to be. Maybe you don't need an object for the win32 case. But it generally makes for easier porting later on if you do need one.
    It also easily paves the way for multi-screen use
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  4. #4
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Erm, this is C++, though? While certainly Salem's methods are good for writing portable code, the code itself is less good for C++ and more so for C...
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  5. #5
    Registered User
    Join Date
    Feb 2006
    Posts
    21
    Thanks for the info. So it seems its just different source files and different makefiles then for the "professional" method. Hmm, Isn't the preprocessor if statements a better method? (well at least for smaller functions). If im missing something then let me know please.

  6. #6
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,659
    Consider that if this were a large project with many people working on it, that the person responsible for the win32 version may be different to the person responsible for the linux version.

    Separate files - no dependencies, except for API changes.
    One big file - merge hell.

    > Hmm, Isn't the preprocessor if statements a better method? (well at least for smaller functions
    How small?
    #ifdef WIN32
    #elif DOS
    #elif LINUX
    #elif BSD
    etc etc

    Half a dozen systems, and your few line function is a page long.


    > Hmm, Isn't the preprocessor if statements a better method? (well at least for smaller functions
    Alternative answer.
    For the most part, you can clump all the *IX systems together under say screen_posix.c
    Over large chunks of POSIX, most of them do the same thing. Using the pre-processor to sort out the minor differences is perhaps a good thing.


    There is no single answer, just a box of tools to play with.
    But FWIW, having some ideas before you start is a hell of a lot better than simply doing a bunch of stuff and then realising "Oh, I need to port it to fluglesys" as well.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  7. #7
    Registered User
    Join Date
    Feb 2006
    Posts
    21
    Cheers for the info. Time to head back and starting hacking away into seperate sources then, and there was me all big headed that i managed to get something to work on two systems with little effort lol... OK next question, instead of starting a new thread, altho it prolly should go in linux programming section...

    CMake or GNU make?

    currently ive got my library setup to use Cmake, generally as its massively easier to create the makefiles, (ive no clue how to start with configure scripts/makefiles etc). Based on peoples experiences, is there any difference to what method you use to get a program compiled, or is it just developer preference?

  8. #8
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,659
    > CMake or GNU make?
    I've no idea - check availability on your intended target systems.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Feedback: compiling games cross platform
    By Clayton in forum C++ Programming
    Replies: 3
    Last Post: 08-27-2010, 11:14 AM
  2. Cross platform XML library
    By Josh Kasten in forum C++ Programming
    Replies: 2
    Last Post: 04-09-2007, 04:04 PM
  3. load gif into program
    By willc0de4food in forum Windows Programming
    Replies: 14
    Last Post: 01-11-2006, 10:43 AM
  4. Question..
    By pode in forum Windows Programming
    Replies: 12
    Last Post: 12-19-2004, 07:05 PM
  5. cross platform game programming
    By xddxogm3 in forum Game Programming
    Replies: 13
    Last Post: 08-22-2004, 09:40 AM