In article <MCOOK.94Sep22174655@galaga.lna.logica.com>
michaelc@lna.logica.com writes:

|> >>>>> "dbuck" == Dave Buck <dbuck@superior.carleton.ca> writes:

|>     dbuck> We had a general rule that there should be NO conditional
|>     dbuck> compilation (#if or #ifdef) within the body of the code.

|> How do you handle the situation where a function has drastically different
|> implementations on different platforms?

I normally write a different version for each platform, in a different
file.  My main source just includes the file with the platform
dependant code.  Each platform has its own subdirectory where its
source files are kept.  Thus, which source actually gets compiled
depends on what -I option I give the compiler.
--
James Kanze      Tel.: (+33) 88 14 49 00     email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

>>>>> "dbuck" == Dave Buck <dbuck@superior.carleton.ca> writes:

    dbuck> We had a general rule that there should be NO conditional
    dbuck> compilation (#if or #ifdef) within the body of the code.

How do you handle the situation where a function has drastically different
implementations on different platforms?

    dbuck> Conditional compilation was allowed only in the platform-specific
    dbuck> module (a mistake I later regretted)

Do you mean to say that you wish you had outlawed conditional compilation
altogether, or that you wish you had allowed conditional compilation in other
headers, too?

Michael.

In article <Cw98J8.7KJ@cunews.carleton.ca> dbuck@superior.carleton.ca (Dave Buck) writes:
>I've had experience in creating portable C code (not C++ code), so I
>may be of some help...
>...
>   - Don't be lazy with the language even if your compiler allows you
>to.  Follow the ANSI spec as closely as possible.  Eg.
>
>             char x[100];
>             call_function (&x);
>
>      On some compilers, this produces a warning that the '&' is not
>needed.  Take it out or use &x[0].

I think you're missing a few things.  If the function to be called was
declared as:

 extern void call_function (char (*arg)[100]);

then (a) no C or C++ compiler should produce a warning of the kind you
describe, and (b) taking out the ampersand would be a serious mistake.

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

>>>>> "erich" == Eric Herrmann <erich@austin.lockheed.com> writes:

    erich> I am beginning to develop an application using a particular
    erich> vendor's C++ compiler and need to ensure that my source code will
    erich> be compilable by other vendor's compilers.

The only really reliable way to do that is to buy the other vendors'
compilers, and compile and test your code using each compiler.  Each compiler
is bound to have quirks, especially since the standard is still evolving.

M.

In article <357jqi$n65@antares.Austin.Lockheed.COM> erich@austin.lockheed.com (Eric Herrmann) writes:
>I am beginning to develop an application using a particular vendor's
>C++ compiler and need to ensure that my source code will be compilable
>by other vendor's compilers.  This issue can not be resolved by using
>the GNU C++ compiler.

In my experience there are two kinds of `portability' claims that can be
made about any given piece of software:

 a)  It is `portable'.
 b)  It is `ported'.

The second claim carries more weight that the first... especially if it
includes a specification of the particular compiler (i.e. brand _and_
version number), the particular operating system, and the particular
hardware platform to which the software is alleged to have been ported.

I myself had a medium-sized ANSI C program which I formerly claimed was
`portable' between UNIX and DOS systems simply because I had compiled and
run the program with one popular C compiler on DOS.  Much to my dismay,
I later learned just how empty my own claim of portability was, and I
spent several weeks getting the bloody thing to compile and run with
three other brands of DOS-based ``ANSI'' C compilers.

I guess all I'm trying to say is that a claim that a piece of software
is `portable' is not really all that meaningful, whereas a claim that it
is `ported' says a lot more.  Likewise, if you *really* want your code
to be portable, there's only one real way to insure that.  Port it.

>What I assume I need is either a defined
>approved industry standard that I can follow....

Don't we all!  Join the club.

(Note however that ever when there _is_ a standard, that's no guarrantee
that all the compilers you care about will instantly be completely confor-
mant and/or totally bug-free overnight.  In other words, there will _still_
be an ``effort gap'' between `portable' code and `ported' code.)

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

In article <357jqi$n65@antares.austin.lockheed.com>,
Eric Herrmann <erich@austin.lockheed.com> wrote:
>I am beginning to develop an application using a particular vendor's
>C++ compiler and need to ensure that my source code will be compilable
>by other vendor's compilers.
>Any answers on how to
>ensure C++ portability, or directions to already published articles
>(ftp sites?), or email addresses of experts, would be appreciated.

I've had experience in creating portable C code (not C++ code), so I
may be of some help.  The program is DKBTrace which is now the POV-Ray
raytracer.  It has been compiled and run on Amiga's (using SAS/C),
PC's (using GCC, Borland C, Watcom C, Intel Code Builder, and a bunch
of others), and a wide variety of UNIX platforms including Sun, HP,
etc.

Note: Some of the techniques used in making POV-Ray portable are not
conventional practice in the C/C++ programming world.  You can assess
them and decide for yourself.

In DKBTrace/POV-Ray, we were fortunate that the only graphics
functions needed were to initialize the screen, draw a pixel of a
certain color at an X,Y coordinate, and close the screen.  This made
things easier by making the rest of the package independent of the
graphics system.

Graphics-specific routines were included in a separate source code
file which was compiled and linked with the application.  Each
platform also had a platform-specific header which was included by all
modules in the package.  For simplicity, this file had to be named
'config.h'.  So, if you were compiling on a UNIX platform, you had to
rename 'unixconf.h' to 'config.h' before compiling.

We had a general rule that there should be NO conditional compilation
(#if or #ifdef) within the body of the code.  Conditional compilation
was allowed only in the platform-specific module (a mistake I later
regretted) and in the main include file to define any needed macros
not defined by the config.h file:

    trace.h:

        #include "config.h"

        #ifndef SOME_SYMBOL
        #define SOME_SYMBOL some_value
        #endif

Within the core of the code, we allowed no:
    #ifdef SUN
type statements.

Some portablility issues we ran into were:
   - ints are 16 bits on some system, 32 bits on others.  Use a macro
to define ints of the right size, eg. INT16.

   - When writing ints to a file, don't use unions or pointer tricks
to access the individual bytes.  IBM's store ints in a different order
than some other processors.  Use / and % instead.

   - use a macro for the 'main' routine.  Some systems have different
syntaxes for 'main'.

   - beware of printf's.  Some systems don't allow you to easily call
printf because they are windowing systems and have nowhere to print
the text.  Using macros here is tough because of the variable number
of arguments.

   - Watch scanf formats.  Some languages use "%d" where others use
"%ld" to read in the same value with the same precision.  Macros help
here because they can be defined in the platform-specific file.

   - Don't be lazy with the language even if your compiler allows you
to.  Follow the ANSI spec as closely as possible.  Eg.

             char x[100];
             call_function (&x);

      On some compilers, this produces a warning that the '&' is not
needed.  Take it out or use &x[0].

   - We wanted to support pre-ANSI as well as ANSI compilers.  For
function prototypes, we used a macro called PARAMS:
    #ifdef __ANSI__
    #define PARAMS(x) x
    #else
    #define PARAMS(x) ()
    #endif

      int function_declaration PARAMS((int a, int b, char *c));

   - Make your identifiers unique names.  This includes all function
names and variables.  For example, in one function, someone once used
'min' and 'max' as variable names.  On some systems this didn't
compile because 'min' and 'max' were defined as macros that required
parameters.

   - The last and most important rule is to compile it with every
single compiler you can get hold of and on every platform you can
access.  It's tough getting a truly portable program and even when you
think you have one, you'll find some little problem you missed.

I hope this has been useful.  Good luck.

David Buck
dbuck@ccs.carleton.ca

_____________________________________________________________________
| David K. Buck                 | My employer is not responsible for|
| dbuck@ccs.carleton.ca         | my opinions.  In fact, they don't |
| Original author of DKBTrace   | even know I have this account.    |
|_______________________________|___________________________________|

I am beginning to develop an application using a particular vendor's
C++ compiler and need to ensure that my source code will be compilable
by other vendor's compilers.  This issue can not be resolved by using
the GNU C++ compiler.  What I assume I need is either a defined
approved industry standard that I can follow, or a list of AT&T 3.0
features that are anticipated to change with the approval of the ANSI
standard (templates, exception handling??).  Any answers on how to
ensure C++ portability, or directions to already published articles
(ftp sites?), or email addresses of experts, would be appreciated.


Thanks,
Eric Herrmann

At least in the PC world, some C++ compilers let you specify the
portability of your code, including ANSI compatibility.  Non-portable
(non-ANSI) code will get spit out by the compiler as errors?

Such a compiler switch might be available on your compiler.  Your best
portability bet is to write only ANSI-compatible code.

In article <357taq$fhs@crl7.crl.com> robtcram@crl.com (Robert H. Cram) writes:

> At least in the PC world, some C++ compilers let you specify the
> portability of your code, including ANSI compatibility.  Non-portable
> (non-ANSI) code will get spit out by the compiler as errors?
>
> Such a compiler switch might be available on your compiler.  Your best
> portability bet is to write only ANSI-compatible code.

That's a little bit meaningless, unfortunately, since there is no ANSI
standard for C++.  There's a working document that will eventually
become a standard, but that's not at all the same thing.  And, I might
add, I don't know of any compiler that implements everything that the
working document specifies at this moment.  (Not surprisingly, of
course, since it changes.)  I've never seen a compiler that implements
namespaces, the new bool type, the STL, or the new rules on the scope
of variables declared in for loops.

If you stick to the ARM (including templates and exceptions), you
should be mostly safe.  Not completely, but mostly.
--

                               --matt