There are a number of issues to deal with in making a software package portable. One of these concerns the possibility of collisions in "name space." Often a software library is used in conjunction with other software; either the author's own code, or other third-party librarys. This becomes problematic if two or more libraries have chosen a common name for a function and/or variable, for then the linker will not know which library module to assocate with the symbol in the user's code, or perhaps even in the other libraries.Portability Issues and Naming Conventions
This is called "name space collision" and can be avoided if the functions and variables in a library intended to be portable are named uniquely. To this end classes, variables and type names in the libraries provided here have been (in almost every case) prefixed with a three-letter acronym designating the library in which the code resides. Examples include the mvl_video_manager class, the gml_generic_fitter class and the iml_fcomplex_image class.
A second portability issue involves scalar type sizes and ranges in C and C++ across platforms. This mostly involves the problem that on 16 bit CPUS under Windows 3.x and DOS, an int defaults to a short integer (two bytes) in most compilers. Conversely on many 32 bit CPUs, especially under various flavors of Un*x, and on more modern Macs, an int defaults to a long integer (four bytes). A common solution top this problem, and the solution used here, is to employ the ANSI C and C++ typedef or #define facility to create names for scalar types. These alternative names allow clear and unambiguous variable typing of the desired size. The list of type names and what they represent are listed here for your convenience and can be found in the file iml_port.h.
The type names, C/C++ definition, and the size of the scalar variable are given in the following table. The entry in the NAME column indicates what has been used in the library code.
The varible-size problem also occurs with pointers because Intel/DOS box compilers can have segment-relative 16 bit pointers (if this sounds like gobbledygook, it is; don't worry about it). This is accounted for by using the following on PC's (by checking for the Borland C++ compiler macro __BORLAND_CPP__ )
NAME DEFINITION WHAT IT IS IML_UBYTE unsigned char unsigned 8-bit integer IML_BYTE signed char signed 8-bit integer IML_USINT unsigned short int unsigned 16-bit integer IML_SINT signed short int signed 16-bit integer IML_LINT unsigned long int unsigned 32-bit integer IML_ULINT signed long int signed 32-bit integer ML_FLOAT float 32-bit floating point (assumes IEEE format) IML_DOUBLE double 64-bit floating point (assumes IEEE format)
and the following on all other machines.
NAME DEFINITION WHAT IT IS IML_PTR huge * 32 bit, normalized pointer IML_REF huge & 32 bit, normalized reference
You are welcome to use these same scalar-variable types in your own code.
NAME DEFINITION WHAT IT IS IML_PTR * 32 bit pointer IML_REF & 32 bit reference