[Mingw-users] No MINGW defect

[Jerry v. D. <jv...@at...>]

> When we say about ANSI/ISO C++ code we mean code that compiles anywhere
> (even if it contains system extensions, like system("pause");). A strict
> ANSI C++ switch should produce errors or warnings for code that does not
> compile everywhere.

Ok, you have a fundamental misconception here. Not about compilers, but
about standards. 

The task of a compilation system for a specific language is to implement that
language standard. Most compilers vendors add additional capabilities to their
compilers to differentiate their product from their competitors and hopefully
create a customer lock-in situation. A strictly comforming compiler (or
switch) means in practice nothing more than to flag the use of extensions as
errors and perhaps add some standard conforming features.

This, however, has nothing to do with portability. Portability has many sides
to it, the two important ones are IMHO language and platform.

Some language definitions are more portable than others. I consider C++ more
portable than C, and Ada more portable than C++. This has to do with the
features a language offers and the way they are defined and can be used.

Your problem is in the second category: platform dependencies. You probably
realize that no language actually tackles this problem. They solve it by
adding a standard library that is expected to be available on most systems. 
But even this is not garanteed to always work, a C program running on a bare 
board may try to use say printf, but if there is no display facility on the 
board, it won't work. So you have a non-portable program, even though the 
program is perfectly standard conforming.

For most real-life program this is a problem, as a you usually need to access
platform specific functions do get things done. These platform specific
functions are usually in additional libraries, and specified in some sort of
header files. These header files can still be defined to conform strictly to
the language, although their functions will only be available on a specific
platform. However, the compiler can not tell you this. It only checks if the
definitions are correct, not if the actual functions are available when you 
run the program (especially in these days of shared libraries and DLL's).

One solution to this problem has been the development of a POSIX standard that
defines how most platform specific functions should be specified, so that
programs using these POSIX conformant definitions would be portable across
different platforms. This has been very successful, but alas not all platforms
implement this standard. Windows being a well known exception (the cygwin
project is for a large part about creating a POSIX compliant layer on top of 
the Win32 API, to enable to you to compile and run POSIX compliant programs on
Windows). 

So in conclusion there is no garantee that a standard conforming program will
be portable, and as the compiler cannot differentiate between header files that
you wrote and provide an implementation for, and header files that depend on
platform specific functionality, there is no way for a compiler to to 
automatically check for this either.

Of cource, if you write code specifically for Windows (and this is still by
far the largest market), you're biggest concern is tracking the changes in the
Win32 API. Which requires MS-savvy engineers. However, if there are other 
platforms is sight (or for example contractual obligations) more is needed.

One route is to use a propriety system that is available on all your target
platforms (ie Delphi/Kylix for Windows/Linux, or with more limitations JAVA
and .NET, which for the most part exchange productivity for performance).

However the normal route is to have engineers who know what they are doing 
with regard to portability. The normal approach being to encapsulate platform 
dependenties in easy to identify and replace functions, that can be easily 
adapted for a new platform. And use as many platform independent libraries as 
possible. For example using wxWindows or GTK for the GUI, instead of calling 
the native Win32 API for this.

So, as so often in our business, portability is not a function of a mechanical
device like a compiler, but of the knowledge and creativity of the people 
creating the product.

gr.
Jerry.

-- 
--  Jerry van Dijk   | email: jv...@at...
--  Leiden, Holland  | web:   users.ncrvnet.nl/gmvdijk