In article <36420A8E.7415@noSPAM.central.beasys.com>,
  dtribble@technologist.com wrote:
> Where I work, we write C++ code that is designed to run on several
> operating systems (currently, several flavors of Unix and Win/NT,
> with more in the furture).  Thus we must code in a common subset of
> C++ that all of our target platforms support; I like to call this
> subset "GCD-C++", meaning "greatest common denominator C++".

A lot of these rules are good advice for anyone writing C++ on any
platform. Where I work, we have a few cross-platform projects, but
we have many more single-platform projects.

With bitter experience behind us, you would think we would be
willing to follow most of your rules for all of our projects. Sadly,
this is not the case. Most of our single-platform projects are
written with the attitude that if it works, it must be correct.
Which is a shame; it costs so little to follow these rules up-front,
and it costs so much to reform the code after the fact.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

[ moderator's note: This cross-posted discussion has migrated
  away from anything suitable for comp.std.c++. I've redirected
  followups to gnu.g++.help alone. -sdc ]

Excellent explanation, I kept a local copy of this for future reference. But
I kindly disagree the following:

- For HP and SUN which I am working on right now, you can have a pretty
decent vendor compiler, for       other platforms, you can always have
third-party ones, KCC, Apogee, EPC, free G++( which in my opinion, is better
than SUN's C++4.2 which I bought for 1500 bucks. ). They can all support
complicated templates, bool,
static_cast, exceptions, RTTI, STL.

-Avoid using some really new key words, namespace, RTTI, etc.

-Use STL where is possible, this might be a single important reason why you
should use c++. The above
compiler all support STL.

-Avoid using macro, use inline instead.

Thanks,

Nortel Network
Wei.



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <71ve9p$emo$1@nnrp1.dejanews.com>, AllanW@my-dejanews.com
writes
>With bitter experience behind us, you would think we would be
>willing to follow most of your rules for all of our projects. Sadly,
>this is not the case. Most of our single-platform projects are
>written with the attitude that if it works, it must be correct.
>Which is a shame; it costs so little to follow these rules up-front,
>and it costs so much to reform the code after the fact.

And if only everyone developed good coding habits you would rarely need
to distinguish where the code was to be used.


Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David Wieringa wrote:
> We're porting some software to C++ (from another language) under the
> Solaris 2.5 operating system.  We will probably also port this to AIX
> in the future.
>
[snip]
>
> Can anyone give me ideas where we might run into porting problems? (as
> far as the C++ language and standard library go)  I haven't been able
> to keep up with the changes to the standard, but I do believe I
> remember some things changing names and such (eg some stream classes).

Where I work, we write C++ code that is designed to run on several
operating systems (currently, several flavors of Unix and Win/NT,
with more in the furture).  Thus we must code in a common subset of
C++ that all of our target platforms support; I like to call this
subset "GCD-C++", meaning "greatest common denominator C++".

We have a coding guidelines document that lists the do's and don't's;
you should probably do the same.

Here are some basic points to remember:

                A FEW GOTCHAS OF C++ PORTABILITY

- Nested classes are not fully supported by all compilers, so we
  don't use them.

- Only simple templates are supported.  (No specializations or
  partializations, nor template classes containing other template
  classes.)  Template instantiation is also anemic, so we keep
  our template classes fairly simple, and use helper implementation
  classes to do most of the actual work.

- We must simulate the 'bool' type (using typedefs or macros) on
  some platforms.

- We must simulate the 'static_cast' operators et al with macros
  on some platforms.

- We implement 'new(nothrow)' by hand on some platforms.

- Some new keywords are entirely absent and can't be simulated
  very well (such as: explicit, typename, typeid, mutable), so we
  don't use them.  It is a good idea to #define them as invalid
  token sequences, though, to prevent their accidental use on
  systems that don't support them.

- Support for exceptions is so anemic, we can't use them at all.
  (And hence the need for 'new(nothrow)'.)  This means that
  constructors and destructors should be kept simple, so that they
  don't do anything that would otherwise cause an exception.

- Namespaces are not supported on most of our platforms, so we
  either 1) use them only on those systems that support them by
  wrapping them in '#if HAS_NAMESPACE' conditionals, or 2) don't
  use namespaces at all.

- The STL is nonexistent on at least one of our platforms, so we
  implement our own small set of STL-like classes.

- We keep source filenames relatively short (less than 25 chars)
  and all lower case.

- We keep static initializers simple, avoiding dynamic
  initializations where possible.

- We don't make too many assumptions about the sizes of data types,
  especially 'int', 'long', and pointers.

- We don't make too many assumptions about the alignment of data
  types, but always assume that the most restrictive alignments are
  in effect.

- We don't assume any particular byte order within data types.

- We don't assume that 'char' is signed or unsigned.

- We use 'inline' sparingly.

- We don't assume that the standard library is thread-safe.

- We avoid OS-specific system calls (e.g., fork()).  We prefer to
  wrap these kinds of calls into a class that has platform-specific
  implementation files, thus isolating the rest of our code from
  the gory details and allowing it to be more portable.

We put the portions of the language that must be simulated into
a common header file (which we call "compiler.hpp") whose contents
are platform-specific.  Every C++ source file must #include this
header.

As time goes by, we hope to increase the scope of GCD-C++ (and to
diminish the size of the "compiler.hpp" header), but we expect it
to take at least two years for all our compiler vendors to catch
up to the full standard.

-- David R. Tribble, dtribble@technologist.com --


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]