I recently debated a fellow programmer who believes that C99 code is also
legal C++, under his assertion that C++ is a superset of "C" in the general
sense. I, on the other hand, read the C++ standard as explicitly deriving
from C89.

This question is an issue when using compilers such as GNU's gcc 3.x, which
supportsd most of C++ and allows C99 code in C++ programs. While my
colleague is quite adventurous about such things, I am reluctant to use a
C99 keyword like "restrict" in "portable" C++ code.

So am I just being a conservative old fuddy-duddy, or am I taking the wise
path by sticking to C89 in my C++?

--
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
No ads -- just very free (and somewhat unusual) code.
Algorithms, evolutionary computing, and fun stuff.

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

In article <%PZo8.19996$K52.2921033@typhoon.tampabay.rr.com>, Scott
Robert Ladd <scott@coyotegulch.com> writes
>I recently debated a fellow programmer who believes that C99 code is also
>legal C++, under his assertion that C++ is a superset of "C" in the general
>sense. I, on the other hand, read the C++ standard as explicitly deriving
>from C89.
>
>This question is an issue when using compilers such as GNU's gcc 3.x, which
>supportsd most of C++ and allows C99 code in C++ programs. While my
>colleague is quite adventurous about such things, I am reluctant to use a
>C99 keyword like "restrict" in "portable" C++ code.
>
>So am I just being a conservative old fuddy-duddy, or am I taking the wise
>path by sticking to C89 in my C++?

You are NOT being conservative enough. C++ is NOT a superset of any
version of C. The incompatibilities between C89 and C++ are few (because
we worked hard to make it so) but they exist and are not entirely
trivial. It is even possible to write code that silently changes between
C and C++, though that is usually fairly contrived:

int main{
  if(sizeof('a') != sizeof(int)
      puts("You are not using a conforming C compiler");
  else if(sizeof(char) == sizeof(int))
      puts("Your compiler's char is unusually large, and may"
                "be either a C or C++ one");
  else puts("You are  not using a conforming C++ compiler");
}

While nothing prevent you having both 16-bit char and 16-bit int such
platforms are rare to non-existent. Unless char and int are the same
size you can determine whether your compiler is a C or C++ one because
char literals are of type int in C and char in C++.



--
Francis Glassborow
Check out the ACCU Spring Conference 2002
4 Days, 4 tracks, 4+ languages, World class speakers
For details see: http://www.accu.org/events/public/accu0204.htm

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Scott> I recently debated a fellow programmer who believes that C99
Scott> code is also legal C++, under his assertion that C++ is a
Scott> superset of "C" in the general sense. I, on the other hand,
Scott> read the C++ standard as explicitly deriving from C89.

You're right; he's wrong.

Scott> This question is an issue when using compilers such as GNU's
Scott> gcc 3.x, which supportsd most of C++ and allows C99 code in C++
Scott> programs. While my colleague is quite adventurous about such
Scott> things, I am reluctant to use a C99 keyword like "restrict" in
Scott> "portable" C++ code.

Rightly so.  "restrict" is not a reserved word in C++, and any
C++ implementation that says otherwise is not following the standard.

Scott> So am I just being a conservative old fuddy-duddy, or am I
Scott> taking the wise path by sticking to C89 in my C++?

You're taking the wise path.

Here's an important part of the problem: Under ISO rules, when a
standard X refers to another standard Y, X must explicitly state
whether it intends to refer to the most recent version of Y or to a
specific version.

Now, consider the situation in which the C++ committee found itself
while developing the C++ standard.  It wanted to incorporate as much
as possible of the C standard by reference, but if it referred to the
most recent version of the C standard, then when that standard was
published, everything in it would immediately become part of C++.

You might consider that to be a good state of affairs, and it would
certainly have advantages.  But it would also be certain to create
conflicts with the C++ standard, and there would be no clear guidance
as to how to resolve those conflicts.

Even figuring out what the conflicts are would be difficult.  For
example, at one point the C++ committee sent a formal request to the C
committee to say what the conflicts were that they knew about between
the (then) forthcoming C99 standard and the (then) draft C++ standard.
The answer was that the C committee did not have time on their
schedule to answer that question.  If the C committee doesn't even
know what the potential conflicts are, how can the C++ standard
possibly admit all those unknown conflicts?

So the C++ committee did the only thing it could:  Incorporate the
C standard as it existed at the time the C++ standard was published.
I have no doubt that the next revision of the C++ standard will take
a close look at C99 and figure out how best to adopt its ideas.

--
Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Scott Robert Ladd wrote:
>
> I recently debated a fellow programmer who believes that C99 code is also
> legal C++, under his assertion that C++ is a superset of "C" in the general
> sense. I, on the other hand, read the C++ standard as explicitly deriving
> from C89.

Basically, he's wrong. Neither C89 nor C99 is a strict subset of C++.
Many features of C89 were included in the C++ standard by reference, and
a few previously C++-specific features were added to C99, such as //
comments, and declarations mixed in with statements. However, they're
two independent languages. Writing code that will work in both and do
the same thing in both languages can often be tricky.

However, there's an interesting side issue closely related to this. It's
the claim of some people in (ISO?),  that there's always only one
version of any standard, the current one. According to them, it's no
longer meaningful to claim C89 compliance, because C89 is no longer an
official standard. This actually affects whether or not it's possible to
get a license to print copies of C89. It gets worse. They claim that any
reference to C89 automagically became a reference to C99, the moment C99
was approved, no matter how clearly that reference specifies that it's
referring to a particular previous version of C. Yes, they claim that
this applies to the cross-references that occur in the C++ standard.

There was considerable discussion of this recently on comp.std.c. It
seems that this is a side-effect of rules that were originally intended
for hardware standards. The application of those rules to software
standards is clearly nonsense, but the fact that it's nonsense isn't
sufficient to get the rules changed quickly. It's going to take a bit of
a fight, I gather.

> This question is an issue when using compilers such as GNU's gcc 3.x, which
> supportsd most of C++ and allows C99 code in C++ programs. While my
> colleague is quite adventurous about such things, I am reluctant to use a
> C99 keyword like "restrict" in "portable" C++ code.

In any event, the C++ standard did not do a wholesale #include of the
C89 standard. It incorporates large portions of the C89 standard by
reference, include almost all of the C standard library. However, that
doesn't mean that every feature of C89 is a feature of C++. Annex C
devotes 13 pages to summarizing the ways in which C and C++ differ in
their handling of the many features that they both share.

That said, I would also like to point out that the next release of the
C++ standard is likely to adopt many, but not all, of the new features
of C99. The problem is, there's no way to be certain which features
those will be.

> So am I just being a conservative old fuddy-duddy, or am I taking the wise
> path by sticking to C89 in my C++?

I'd recommend experimenting with the new C99 features - that's how
people learn what works and what doesn't, which is one of the key things
that the committee needs to know when it decides whether to incorporate
them in the next release. However, don't use mixed C99/C++ features in
any critical code until a standard has been approved that incorporates
them.

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

James> However, there's an interesting side issue closely related to
James> this. It's the claim of some people in (ISO?), that there's
James> always only one version of any standard, the current
James> one. According to them, it's no longer meaningful to claim C89
James> compliance, because C89 is no longer an official standard. This
James> actually affects whether or not it's possible to get a license
James> to print copies of C89. It gets worse. They claim that any
James> reference to C89 automagically became a reference to C99, the
James> moment C99 was approved, no matter how clearly that reference
James> specifies that it's referring to a particular previous version
James> of C. Yes, they claim that this applies to the cross-references
James> that occur in the C++ standard.

I don't think that's true.  In particular, I am fairly certain that
there is an explicit statement to the contrary in the ISO drafting
directives.  Unfortunately, my copy of the directives is in my office
and I'm at home right now, so I can't check it.

However, what I believe the situation to be is that any standard can
make a normative reference to any other standard, and when it does so,
it must say explicitly whether it intends to refer to a particular
edition of that standard or to the most recent version.


--
Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]