In article <5ippq5$q2m@fs7.ece.cmu.edu>, dacut@henry.ece.cmu.edu wrote:

>dacut@henry.ece.cmu.edu (David A. Cuthbert) wrote [regarding namespace
>problems]
>
>James Kanze  <james-albert.kanze@vx.cit.alcatel.fr> replied:

>
>>|>  The good news is that the standard is fairly stable now.  Expect these
>>|>  problems to go away shortly as compiler vendors catch up.
>>
>>For what definition of shortly?  ISO C took a couple of years to become
>>widespread; the evolution of C++ involves considerably more.
>

C was standardized in 1989 (8 years ago).

I encounter C code that avoids "void *" and has macros to enable/disable
prototypes all the time.  This is new code following up to date portability
coding guidelines.

Some U**X vendors still ship pre-ANSI compilers as the default with their
systems.  ANSI C costs extra.

We will probably be fighting ANSI/ISO C++ support problems in portable C++
code for more than ten more years.

That said, the problems ARE solvable and I DON'T want to go back to programming
in C.
--
Darron Shaffer
Darron.Shaffer@beasys.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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

David R Tribble <david.tribble@central.beasys.com> writes:

>(Remember that there's a new
>C standard coming out in the next two years or so, so C will be unstable for
>a while as well.)

That's not really a fair point.  C89 (the current version of C) will be
stable for a long time to come.  While C9X won't be 100% backwards
compatible, any backwards compatibility problems due to changes in C9X
are going to be very very small.

C9X will cause significant porting problems if you actually use the new
features.  The decision as to whether to (or when to) make use of C9X
features will require the same sort of analysis as the original poster
is currently making with regard to use of C++.  If you stick to C89
features, then you shouldn't have any significant problems.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Steve Roy Karmesin <karmesin@acl.lanl.gov> writes:

|>  With the caveats you mention -- no templates or exceptions -- and a
|>  couple below the portability should be excellent these parts of the
|>  language have been quite stable for some time.

Really.  What about the scope of a variable declared in a for statement?
This is just the most blatent example; there are many others.  The
language is far from stable.

A more accurate statement would be that it is possible (and reasonable)
to write programs that work in both cases.  For example, with regards to
the change of scope of for, one applies the rule: "never use the
variable declared in a for after the end of the for, and never declare
another variable of the same name in the encompassing scope of the for."

|>  What other caveats?
|>
|>  1. You might be using templates when you don't expect to.  iostreams
|>  uses templates.  The main place this could hit you is if you have
|>  forward declarations like:
|>
|>  class ostream;
|>
|>  This won't work anymore.  This is a royal pain, and exactly why this
|>  doesn't work is deeply arcane.  You need to say:
|>
|>  #include <ostream.h>

It's worse that that.  Even things like the type of the flags field in
ios vary from one compiler to the next.  Which makes things like saving
and restoring the flags difficult, even passed the hurdle of what file
to include.

What you'll probably want to do is to create a directory with machine
dependant headers, one per target (and use the correct -I option for the
machine targeted).  In this directory, you'll have a global header file,
to cover general issues (define bool or not, etc., and a typedef for the
correct type for ios::flags).  I also place files corresponding to the
standard iostream include files, but with a suffix (.hh) there.  On
modern systems, these files just include the ISO standard header; on
older systems, iosfwd.hh contains the forward declarations of "class
istream", etc., and the others include iostream.h (or iostream.hpp).

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

dacut@henry.ece.cmu.edu (David A. Cuthbert) writes:

|>  Andrew D Jewell  <avjewe@kaizen.net> wrote:
|>  >My question is, how does the portability of C++ implementations compare with
|>  >the portability if C implementations. If we ignore templates and exceptions
|>  >for the moment, would we be more likely or less likely to run into
|>  >implementation specific issues with C++ compilers as compared to C
|>  >compilers.
|>
|>  Not too well, currently.  Namespaces and header names are in flux,
|>  which makes my life a nightmare when I write a program that has
|>  "#include <iostream>" and uses namespaces extensively, and try to take
|>  it to the older Unix compilers we have at work.

The headers can be handled as I explained in another posting: don't
include them directly, but through a private, machine dependant header,
which does whatever is appropriate for the target.

I'd probably avoid namespaces in application code for the moment.

|>  The namespace problem affects the standard library quite a bit, as
|>  much of it is now in namespace std.  Which means that I have to either
|>  add/remove a bunch of "std::" in my programs, or track down "using"
|>  declarations.

I use the following:

 #if GB_HASNAMESPACE
 #define GB_BEGIN_NS( ns )               namespace ns {
 #define GB_END_NS                       }
 #define GB_USE_NS( ns )                 using namespace ns
 #define GB_USE( ns_elem )               using ns_elem
 #define GB_std                          std
 #else
 #define GB_BEGIN_NS( ns )
 #define GB_END_NS
 #define GB_USE_NS( ns )
 #define GB_USE( ns_elem )
 #define GB_std
 #endif

In practice, I think that I only really use the last two macros:

 GB_USE( strcmp ) ;

or

 if ( GB_std::strcmp( s1 , s2 ) == 0 ) ...

The last is really nice, because it does the correct scope resolution in
both cases.  But it is only useful for the standard library.

|>  The good news is that the standard is fairly stable now.  Expect these
|>  problems to go away shortly as compiler vendors catch up.

For what definition of shortly?  ISO C took a couple of years to become
widespread; the evolution of C++ involves considerably more.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

dacut@henry.ece.cmu.edu (David A. Cuthbert) wrote [regarding namespace
problems]

James Kanze  <james-albert.kanze@vx.cit.alcatel.fr> replied:
>I use the following:
>
> #if GB_HASNAMESPACE
> #define GB_BEGIN_NS( ns )               namespace ns {
> #define GB_END_NS                       }
> #define GB_USE_NS( ns )                 using namespace ns
> #define GB_USE( ns_elem )               using ns_elem
> #define GB_std                          std
> #else
> #define GB_BEGIN_NS( ns )
> #define GB_END_NS
> #define GB_USE_NS( ns )
> #define GB_USE( ns_elem )
> #define GB_std
> #endif

I shudder at these macros, but I see their benefit.  I think that I'm
just tired to seeing macros (they seem to abound in the Windows
headers); they tend to clutter up the syntax so much.

But I don't write production code, either.

>|>  The good news is that the standard is fairly stable now.  Expect these
>|>  problems to go away shortly as compiler vendors catch up.
>
>For what definition of shortly?  ISO C took a couple of years to become
>widespread; the evolution of C++ involves considerably more.

I was thinking of a year to get many of the new stuff introduced
(basically, in the next version that each vendor puts out), and then
two to get everything there and about half of it working.  :-)

I guess this isn't "shortly" for many people (it is for me, since our
new ideas take 5 to 10 years to show up, if at all); that occurred to
me after I sent in the article, but I figured I'd try to let it
slide. :-)
--
David A. Cuthbert (henry.ece.cmu.edu!dacut)
Graduate Student, Electrical and Computer Engineering
Data Storage Systems Center, Carnegie Mellon University
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

I wrote:

>C9X will cause significant porting problems if you actually use the new
>features.

That is not necessarily true.  What I meant to say was converse:

 C9X will cause significant porting problems only if you
 actually use the new features.              ^^^^

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

With the caveats you mention -- no templates or exceptions -- and a
couple below the portability should be excellent these parts of the
language have been quite stable for some time.

What other caveats?

1. You might be using templates when you don't expect to.  iostreams
uses templates.  The main place this could hit you is if you have
forward declarations like:

class ostream;

This won't work anymore.  This is a royal pain, and exactly why this
doesn't work is deeply arcane.  You need to say:

#include <ostream.h>

2. You can't link object files from different compilers.  If your code
depends on building libraries with one compiler and linking that to code
produced with another, it won't work.  The basic deal here is that the
standard doesn't specify how things like virtual tables need to be laid
out, so different vendors are free to use different formats.  This also
shows up in the fact the fact that the standard doesn't specify the name
mangling, so different vendors will use different formats for that.  The
former is the more fundamental problem though; the latter could much
more easily be legislated by the committee.

Steve Karmesin

Andrew D Jewell wrote:
>
> We're thinking of moving our product from C to C++
>
> Our product currently runs on a bunch of UNIX's, VMS, MVS and a bunch of
> other mainframe, mini and micro computer operating systems.
>
> My question is, how does the portability of C++ implementations compare with
> the portability if C implementations. If we ignore templates and exceptions
> for the moment, would we be more likely or less likely to run into
> implementation specific issues with C++ compilers as compared to C
> compilers.
>
> Any pointers to authoritative documents would be helpful, as I have to
> convince my boss too.
>
> Thanks,
> Andy Jewell
> ajewell@cincom.com
> ---
> [ comp.std.c++ is moderated.  To submit articles: Try just posting with your
>                 newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
>   comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
>   Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
>   Comments? mailto:std-c++-request@ncar.ucar.edu
> ]
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Andrew D Jewell <avjewe@kaizen.net> writes:

|>  We're thinking of moving our product from C to C++
|>
|>  Our product currently runs on a bunch of UNIX's, VMS, MVS and a bunch of
|>  other mainframe, mini and micro computer operating systems.
|>
|>  My question is, how does the portability of C++ implementations compare with
|>  the portability if C implementations. If we ignore templates and exceptions
|>  for the moment, would we be more likely or less likely to run into
|>  implementation specific issues with C++ compilers as compared to C
|>  compilers.

C++ is a large, complex language with many features and no formal
standard (yet).  C is a small, simple language with a formal standard
since 1989.  Does that answer your question?

Realisitically, you can write portable C++, but it is certain that the
compiler differences will be larger than in C (even ignoring templates
and exceptions).

IMHO, however, the real problem lies elsewhere.  You can effectively
write portable programs in either language.  You already know how to do
this in C.  You will have to learn how to do it in C++.

I don't think that anyone would disagree with me that the cost of
learning this will be less in 5 years time (after the standard has been
adopted and all compilers have had time to align themselves with it).
On the other hand, I (and many others) think that C++ has a number of
advantages over C.  The question is: is the cost of not using these
advantages over the next five years more or less than the additional
cost of learning to write portable C++ now?  And there is no simple
answer: the cost of not using the advantages of C++ depends largely on
the actual application (and the cost of writing portable C++ now depends
at least partially on your organization).

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Andrew D Jewell  <avjewe@kaizen.net> wrote:
>My question is, how does the portability of C++ implementations compare with
>the portability if C implementations. If we ignore templates and exceptions
>for the moment, would we be more likely or less likely to run into
>implementation specific issues with C++ compilers as compared to C
>compilers.

Not too well, currently.  Namespaces and header names are in flux,
which makes my life a nightmare when I write a program that has
"#include <iostream>" and uses namespaces extensively, and try to take
it to the older Unix compilers we have at work.

The namespace problem affects the standard library quite a bit, as
much of it is now in namespace std.  Which means that I have to either
add/remove a bunch of "std::" in my programs, or track down "using"
declarations.

The good news is that the standard is fairly stable now.  Expect these
problems to go away shortly as compiler vendors catch up.

>Any pointers to authoritative documents would be helpful, as I have to
>convince my boss too.

I'd look at compiler vendors' home pages and compare the supported
features.
--
David A. Cuthbert (henry.ece.cmu.edu!dacut)
Graduate Student, Electrical and Computer Engineering
Data Storage Systems Center, Carnegie Mellon University
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

"Andy Jewell" <ajewell@cincom.com> wrote:
> We're thinking of moving our product from C to C++
>
> Our product currently runs on a bunch of UNIX's VMS MVS and a bunch of
> other mainframe, mini and micro computer operating systems.
>
> My question is, how does the portability of C++ implementation compare with
> the portability if C implementations. If we ignore templates and exceptions
> for the moment, are would we be more likely or less likely to run into
> implementation specific issues with C++ compilers as compared to C
> compilers.

Since implementations of C++ vary at the moment, and since the draft Standard
of C++ hasn't yet been approved, you will find that for the time being (i.e.,
for the next year or two), C++ compilers will vary somewhat.  More so than
C compilers, since the C Standard has been out since 1989.

Our code is about half C and half C++, and we port to a number of machines
similar to you.  We chose C++ for our new stuff in order to move into the
90's with object-oriented design and coding.  C is great, but only up to a
point, beyond which you need something stronger design-wise, i.e., classes.

We keep track of porting difficulties as we port from one machine to another.
Such difficulties include compiler deficiencies, linker differences, shared
library support differences, etc.  Obviously, we don't use all the capabilities
of C++, but restrict ourselves to a portable subset.  This excludes exceptions
and complicated templates (simple templates are okay, though), and a few other
nits.  (Some of our compilers are a couple of years old.)

So it's a trade-off: if you want more portability, stay with C; if you want
better code, go with (a subset of) C++.  Keep in mind that 'better code'
isn't automatic when you go with C++, but C++ gives you more ways to
structure, encapsulate, separate, and protect your data and code than C.
We chose (subset) C++ on our newest project 18 months agor, and we wouldn't
want to go back to C, despite our porting problems.  And bear in mind that
eventually C++ will be as portable as C.  (Remember that there's a new
C standard coming out in the next two years or so, so C will be unstable for
a while as well.)
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

> My question is, how does the portability of C++ implementation compare with
> the portability if C implementations.

One of the big irritations (not hard to fix, but constantly encountered)
is the random differences in header files on different systems. Yes, the
standard headers are pretty standard these days, but if you need to
delve into pieces of the system not covered in the standard you constantly
run into random system functions that are "the same" on all U**x systems,
but have prototypes in different files, have char * instead of void *
(or maybe instead of const char *), etc., etc.

In C this usually only causes warnings. In C++ they are always fatal errors.

Someday maybe everything will be really really standard, but until then
count on spending a lot of time on piddling stuff like casting all your
arguments using macros and defining the macros differently on different
machines...
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Tom.Horsley@worldnet.att.net (Thomas A. Horsley) writes:

>One of the big irritations (not hard to fix, but constantly encountered)
>is the random differences in header files on different systems. Yes, the
>standard headers are pretty standard these days, but if you need to
>delve into pieces of the system not covered in the standard you constantly
>run into random system functions that are "the same" on all U**x systems,
>but have prototypes in different files, have char * instead of void *
>(or maybe instead of const char *), etc., etc.
>
>In C this usually only causes warnings. In C++ they are always fatal errors.

That depends on the compiler.  With GNU C++, for example, they are usually
just warnings.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

We're thinking of moving our product from C to C++

Our product currently runs on a bunch of UNIX's, VMS, MVS and a bunch of
other mainframe, mini and micro computer operating systems.

My question is, how does the portability of C++ implementations compare with
the portability if C implementations. If we ignore templates and exceptions
for the moment, would we be more likely or less likely to run into
implementation specific issues with C++ compilers as compared to C
compilers.

Any pointers to authoritative documents would be helpful, as I have to
convince my boss too.

Thanks,
Andy Jewell
ajewell@cincom.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]