"Portable" Code and variable sizes

I was reading a message on this board regarding int sizes and portability. The premise makes sense to me: on one system an int may be x bytes and on another y bytes, and thus the code isn't portable.

My question is, is portibilty an issue at the .exe level? In other words, the C(++) code I write can't be compiled correctly on a different system if the systems have different int sizes. But what if the .exe file has already been compiled on one system? Can I copy the file to another system and have it work as I expect? Does compiling "fix" an int at a certain size within the .exe file and allow the .exe file to be executed correctly? Or is the .exe file still dependent on the system for allocating variable sizes?

Since I just asked the same question 5 different ways, hopefully one will make sense. Thanks...

Comments

  • [b][red]This message was edited by adrianxw at 2004-5-3 12:50:29[/red][/b][hr]
    : I was reading a message on this board regarding int sizes and portability. The premise makes sense to me: on one system an int may be x bytes and on another y bytes, and thus the code isn't portable.
    :
    : My question is, is portibilty an issue at the .exe level? In other words, the C(++) code I write can't be compiled correctly on a different system if the systems have different int sizes. But what if the .exe file has already been compiled on one system? Can I copy the file to another system and have it work as I expect? Does compiling "fix" an int at a certain size within the .exe file and allow the .exe file to be executed correctly? Or is the .exe file still dependent on the system for allocating variable sizes?
    :
    : Since I just asked the same question 5 different ways, hopefully one will make sense. Thanks...
    :

    If you need a 32 bit entity specify long int or unsigned long int, if you need a 16 bit entity specify short int or unsigned short int, int by itself can be different sizes.

    Med venlig hilsen,

    Adrian...



  • [b][red]This message was edited by stober at 2004-5-3 13:29:8[/red][/b][hr]
    I think you may have misunderstood what you read. Yes, it is true that the size of a data item can be different among operating systems. That however does not make the source code non-portable, only the data that's produced by the code. If you stick structly to ANSI C/C++ your source code should be portable on all operating systems. Where you run into trouble is when you write code that depends on the size of a variable -- for example if I attempt to pass an int to a function that expects a short (assume sizeof(int) == sizeof(short)) or attempt to memcpy an int using the int's wrong size. The upcoming 64-bit version of M$ Windows will have a lot of problems like that because some programmers use int's to represent HANDE -- the sizeof a HANDLE in 64-bit Windows is not the same as it is in 32-bit Windows, so the program will not be directly portable without some code changes.

    It is the data that the program produces that may not be portable across operating systems -- and this problem is frequently found when exchanging data between unix and MS-DOS/Windows and/or MAC. In this case the byte order of the data is also different. This doesn't mean that the data cannot be exchanged, but that programmers have to recognize this and code for it.





  • : [b][red]This message was edited by stober at 2004-5-3 13:29:8[/red][/b][hr]
    : I think you may have misunderstood what you read. Yes, it is true that the size of a data item can be different among operating systems. That however does not make the source code non-portable, only the data that's produced by the code. If you stick structly to ANSI C/C++ your source code should be portable on all operating systems. Where you run into trouble is when you write code that depends on the size of a variable -- for example if I attempt to pass an int to a function that expects a short (assume sizeof(int) == sizeof(short)) or attempt to memcpy an int using the int's wrong size. The upcoming 64-bit version of M$ Windows will have a lot of problems like that because some programmers use int's to represent HANDE -- the sizeof a HANDLE in 64-bit Windows is not the same as it is in 32-bit Windows, so the program will not be directly portable without some code changes.
    :
    : It is the data that the program produces that may not be portable across operating systems -- and this problem is frequently found when exchanging data between unix and MS-DOS/Windows and/or MAC. In this case the byte order of the data is also different. This doesn't mean that the data cannot be exchanged, but that programmers have to recognize this and code for it.
    :
    :

    Well, since he was asking about the .exe level, I kind of assumed he would be working on one OS family. I wouldn't expect an .exe compiled for Win32 to work on a Unix box or a Mac.

    I kind of assumed that he was concerned about running a Win32 app under Longhorn or something.

    My comments were simply to avoid the problem you mention viz. passing an "int", by specifying functions to take a short, or a long, then if he passes the wrong thing, it won't compile, thus his problem should not arise.

    I know there are people that store handles int int's, but frankly, that is poor coding IMHO. There are a lot of MS specified types that are there specifically to address these kind of problems. People want to "fool" the compiler to get the job done, probably deserve what they get!

    Med venlig hilsen,

    Adrian...

  • I wasn't attempting to imply you were wrong -- just providing some additional information.
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories

In this Discussion