In standards , some parts are left to "Implementation dependent" . One of
the most important incompatibilities come from such parts .
To obtain a "good" portability , such points should be considered and be
avoided as much as possible .
Another possibility is to set the same standard option in compilation and
use many compilers for the same source tree in the same operating system .
If that program is accepted as correct by many compilers , it means that
compiler dependent parts are not used within the same operating system .
Another approach may be to use an NFS server , then compile the same
program source tree from different client operating systems with the SAME
compiler kind such as Clang for its operating system to remedy differences .
If a group of compilers are used in that way , it is very likely that
differences will be reduced as much as possible .
Another difference source is operating system dependencies . These should
be handled by "ifdef os ..." statements because some features are very
different in different operating systems which they can not made equivalent
To reduce the portability difficulties , one of the ways may be to use
parts solely handling operating systems or compiler dependencies .
For example : Time : Assume in different operating systems , the time
routines are very different and your program is using a large number of
time routine calls .
It is possible to use "ifdef os ..." statements in every call point and use
relevant call statements .
OR write a time routine yourself with common parameters and call this
routine from where it is needed . Inside of that single routine use
relevant "ifdef os ..." statements , i.e. , collect operating systems
dependent , compiler dependent parts into such single routines and use your
routines from other places . In that way , you will need to customize a
small number of routines , instead of a large number of other routines .
Algol 68 was one of the best programming languages when it was designed .
The most important deficiency was the decision to leave input / output
"implementation dependent " . Due to this , no one of the implementation
was compatible to another implementation . This "feature" made the Algol 68
as "still born" .
In contrary to Algol 68 , the Fortran defined its rules as complete as
possible . Acceptance was very high and still it is in use .
One very unfortunate situation for the "Standards" are that they are NOT
"standard" : Leaving many parts as undefined because of effects of "LARGE"
ones for their own benefits , i.e. , design of standard are not based on
completely "Science" but mostly "Benefits" .
Thank you very much .
Mehmet Erol Sanliturk