Compile C Code With A CPP Compiler?

[CBFalconer]

.... snip ...

Indeed. This is a last moment addition to the C99 standard
(missing from N869).

Perchance you have accumulated an informal list of those
additions. If so, I think many would be pleased to see it.

 

[Dan Pop]

Perchance you have accumulated an informal list of those
additions. If so, I think many would be pleased to see it.

Well, it's in my head, only. Here are the changes I'm aware of:

From the last part of 6.2.6.2p2 on:

- the corresponding value with sign bit 0 is negated (sign
and magnitude);

- the sign bit has the value -(2**N) (two's complement);

- the sign bit has the value -(2**N - 1) (one's complement).

Which of these applies is implementation-defined, as is
whether the value with sign bit 1 and all value bits zero
(for the first two), or with sign bit and all value bits 1 (for
one's complement), is a trap representation or a normal value.
In the case of sign and magnitude and one's complement, if this
representation is a normal value it is called a negative zero.

3 If the implementation supports negative zeros, they shall be
generated only by:

- the &, |, ^, ~, <<, and >> operators with arguments that
produce such a value;

- the +, -, *, /, and % operators where one argument is a negative
zero and the result is zero;

- compound assignment operators based on the above cases.

It is unspecified whether these cases actually generate a
negative zero or a normal zero, and whether a negative zero
becomes a normal zero when stored in an object.

4 If the implementation does not support negative zeros, the
behavior of the &, |, ^, ~, <<, and >> operators with arguments
that would produce such a value is undefined.

========================================================================

6.3.1.3 Signed and unsigned integers

3 Otherwise, the new type is signed and the value cannot be
represented in it; either the result is implementation-defined
^^^^^^
or an implementation-defined signal is raised.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

========================================================================

6.5.2.3p5 (The first statement in the N869 version is missing in the final
version, which turns implementation-defined behaviour into undefined
behaviour.)

5 One special guarantee is made in order to simplify the use of
unions: if a union contains several structures that share a
common initial sequence (see below), and if the union object
currently contains one of these structures, it is permitted to
inspect the common initial part of any of them anywhere that
a declaration of the complete type of the union is visible.
Two structures share a common initial sequence if corresponding
members have compatible types (and, for bit-fields, the same
widths) for a sequence of one or more initial members.

========================================================================

6.10.8 Predefined macro names

5 The implementation shall not predefine the macro __cplusplus,
nor shall it define it in any standard header.

========================================================================

7.18.1.1 Exact-width integer types

1 The typedef name intN_t designates a signed integer type with
width N, no padding bits, and a two's complement
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
representation. Thus, int8_t denotes a signed integer type with
^^^^^^^^^^^^^^^
a width of exactly 8 bits.

========================================================================

7.20.4.4 The _Exit function

Synopsis

1 #include <stdlib.h>
void _Exit(int status);

Description

2 The _Exit function causes normal program termination to occur
and control to be returned to the host environment. No functions
registered by the atexit function or signal handlers registered
by the signal function are called. The status returned to the host
environment is determined in the same way as for the exit function
(7.20.4.3). Whether open streams with unwritten buffered data
are flushed, open streams are closed, or temporary files are
removed is implementation-defined.

Returns

3 The _Exit function cannot return to its caller.

========================================================================

Any additions to the list are welcome.

Dan

 

[E. Robert Tisdale]

The project relies upon about 10 years worth of legacy 'C' code.
I've been working in C, and, after a few conversations,
I decided that C++ is a better longterm decision for the code.

Correct. The future of C is C++.
You should try to write C code which is compatible with C++.
For example, you should write:

#include <stdlib.h>

.
.
.

int* p = (int*)malloc(n*sizeof(int));

to convert the void* pointer returned by malloc
into a pointer to an int.

 

[Micah Cowan]

Correct. The future of C is C++.
You should try to write C code which is compatible with C++.
For example, you should write:

#include <stdlib.h>

.
.
.

int* p = (int*)malloc(n*sizeof(int));

to convert the void* pointer returned by malloc
into a pointer to an int.

Ridiculous. If you want C++ code, then it's much better to write
C++ code then to try to make C-ish C++ code or C++-ish C
code. When you try to write code that compiles in both, you wind
up using idioms that are considered crappy by knowledgeable
coders of both languages. And there is absolutely no reason to
write C code like this, even if you do plan on moving to C++,
since C++ fully supports linking to C object files, so you can
keep your C code and still use it as-is from within C++ code.

In C, the way to avoid important errors when allocating memory is
to not cast malloc()'s return. In C++, the way to avoid important
errors when allocating memory is to use new (although, I have
used malloc() in situations where being able to use realloc() was
appropriate).

Not to mention that the #include <stdlib.h> above is deprecated
in C++, and may be removed in future versions of the language, so
it's not even forward-compatible, which is allegedly what you
were trying to achieve. And even in the current version of C++,
that method of inclusion will pollute the global namespace, which
is less-than-undesirable.

Conclusion: if you want C code, write good C code. If you want
C++ code, write good C++ code. You're only robbing yourself if
you try to write code that is mediocre for both.

-Micah

 

[Default User]

Correct. The future of C is C++.

I see Trollsdale is at it again.



Brian Rodenborn

 

[E. Robert Tisdale]

There is absolutely no reason to write C code like this
even if you do plan on moving to C++
since C++ fully supports linking to C object files, so you can
keep your C code and still use it as-is from within C++ code.

No!

There is *no* guarantee that you will be able to link
code compiled by a C compiler (or even another C++ compiler)
into a C++ program. The only thing specified by ANSI/ISO C++
is that the extern "C" mechanism will emit C "style" linkage
which means that the symbols left behind in the object file
will be the undecorated function names introduced by the programmer.

 

[CBFalconer]

Correct. The future of C is C++.
You should try to write C code which is compatible with C++.
For example, you should write:

#include <stdlib.h>
.
.
int* p = (int*)malloc(n*sizeof(int));

to convert the void* pointer returned by malloc
into a pointer to an int.

Hogwash. You have just illustrated an excellent reason to write C
code for a C compiler, and C++ code for a C++ compiler. May the
camels nose penetrate your tent.

 

[Richard Heathfield]

No!

Er, yes, actually.

There is *no* guarantee that you will be able to link
code compiled by a C compiler (or even another C++ compiler)
into a C++ program.

There is no guarantee that qsort won't use bubble-sort, either. Can you say
QoI?

The only thing specified by ANSI/ISO C++
is that the extern "C" mechanism will emit C "style" linkage
which means that the symbols left behind in the object file
will be the undecorated function names introduced by the programmer.

And the whole idea of that is to make it possible to link C code into C++
programs. They even /called/ the extension "C". It couldn't be much clearer
- except, of course, to a troll.

 

[Richard Heathfield]

Correct. The future of C is C++.

Incorrect. C++ is a different language, which exists separately. C's future
is C. C++ and C have already split, and have been heading in different
directions for many years.

You should try to write C code which is compatible with C++.

No, you really, really shouldn't.

For example, you should write:

#include <stdlib.h>

.
.
.

int* p = (int*)malloc(n*sizeof(int));

Typical Tisdale nonsense.

Quite apart from the hopelessly daft type dependency inside the malloc, the
spurious cast constitutes unwarranted chumminess with C's sister language.

All code should either do something good or stop something bad from
happening. Your cast does neither.

to convert the void* pointer returned by malloc
into a pointer to an int.

int *p = malloc(n * sizeof *p);

is cleaner, easier to read, and utterly compatible with C++, as is all C
code that is translated by a C compiler and then linked into C++ programs -
a feature which C++ specifically supports with the 'extern "C"' construct.
This is to facilitate code re-use. There is absolutely no need for anyone
to turn C code into pidgin-C++ against a day when they might want to make
it compilable in a C++ compiler.

 

[Micah Cowan]

What important error to you mask when you cast a pointer known to
be a void * to one that can only be assigned to a pointer of the
expected type?


It's compatible today, and will be for at least several years to
come. I'll venture to predict that the next major revision of
Standard C++ will still include the *.h headers of Standard C.
Probably those of C99, in fact.


The C++ Standard actually does a pretty lame job of avoiding
namespace pollution, even with the handful of implementations
that actually follow all its Procrustean rules. You win way
less than you think by avoiding the *.h headers, while losing
way more de facto portability than you think in the bargain.

Well, you still get all the potential macro definitions,
yeah. As to the de facto portability: that sort of portability is
why I avoided C++ for so long, considering how poorly
standardized it was for a long time, and then how poorly the
standard had been followed until somewhat recently. When I cater
to such implementations that can't properly handle #include
<cstdlib>, those same implementations also frequently lack other
important features, to the point where I don't feel like I'm
really coding C++. Generally, if I choose to employ C++ in my
project, I deliberately decide to limit portability to
standard-conformant implementations.

-Micah

 

[Richard Bos]

Darn, and I've *so* wanted to be considered a knowledgable
coder. Forty years wasted. As I've mentioned before, essentially
all of our C code is written to compile as both Standard C and
Standard C++. We find it pretty readable and our customers have
yet to complain about its crappiness.

Is this hand-written or machine-generated code? Different rules apply to
those, you know. Machine-generated code, for example, doesn't need to be
maintainable - you maintain the source that the machine generated the
code from. Hand-written code must conform to much stricter rules,
because we can trust it less.

Richard

 

[Richard Bos]

Mine too.


You mean we should avoid writing anything in C that someone might suspect
would also be good C++?

What a nonsensical reaction! No, we should avoid writing C which is iffy
for no better reason than that it's also legal (but iffy) C++.

Where does that leave comments?

Comments do something good: they explain code to the maintainer.

But it does reassure the reader that you know what kind of storage
you're trying to allocate.

No, it doesn't. It reassures the reader that you can read declarations.
Well, wow.

And it causes a compile-time diagnostic
if you later change the type of the pointer you're assigning to,
without changing the sizeof to match.

That's better, more legibly, more concisely and more dependably done
like this:

int *p = malloc(n * sizeof *p);

(Note also that I moved the pointer in the type. The original was
confusing in that respect, also; int* p,q; does _not_ declare two
pointers.)

Anything that improves readability at no cost in code size
or execution time has to be salutary, in my book.

Yup. Pity that casting malloc() makes the code more complex, larger
_and_ more brittle.

Richard

 

[Richard Heathfield]

[PJP's article didn't show up on my server yet, hence the (partial)
piggy-backing.]

What a nonsensical reaction! No, we should avoid writing C which is iffy
for no better reason than that it's also legal (but iffy) C++.

I agree with all but the first four words. I think we should respect the
fact that P J Plauger is an expert on the C language, even if we happen to
disagree with him on this issue.

Comments do something good: they explain code to the maintainer.
Right.

That isn't the purpose of casts. In any event, as Richard Bos rightly points
out below, the construct:

T *p = malloc(n * sizeof *p);

is always[1] correct for any object type T, so the reader doesn't need
reassuring.

No, it doesn't. It reassures the reader that you can read declarations.
Well, wow.

If we can take the heat out of this, we might get a bit more light.

That's better, more legibly, more concisely and more dependably done
like this:

int *p = malloc(n * sizeof *p);

(Note also that I moved the pointer in the type. The original was
confusing in that respect, also; int* p,q; does _not_ declare two
pointers.)

Not having the original in front of me, I can't tell what you mean for
certain, but if the original layout was: int* p = malloc..., I don't think
it's a big deal, especially if declarations are kept one to a line (which
is my own preference).

Yup. Pity that casting malloc() makes the code more complex, larger
_and_ more brittle.

Right. The key point, IMHO, is readability, and adding spurious casts
impairs readability. As for the whole issue of programming in a subset of C
common to C and C++, I consider this an utterly unnecessary restriction, as
pointless as programming in the common subset of C and COBOL, or C and
BASIC, or C and Pascal. Clearly, Mr Plauger's mileage varies, and I'm not
about to suggest that he changes his business's development strategy on the
basis of a newsgroup discussion! Nevertheless, I can't see myself advising
anyone to adopt that strategy any time soon.

[1] Never[2] say "always".
[2] Or "never".

 

[Default User]

[PJP's article didn't show up on my server yet, hence the (partial)
piggy-backing.]

I haven't seen ANY of his messages, but lots of replies to them. Not
sure what's up with that.




Brian Rodenborn

 

[Joona I Palaste]

[PJP's article didn't show up on my server yet, hence the (partial)
piggy-backing.]

I haven't seen ANY of his messages, but lots of replies to them. Not
sure what's up with that.

The same happened to me. What's with this thing? What do news servers
have against Plauger? Perhaps we should make a poll about who can see
his messages and who can't.

--
/-- Joona Palaste ([email protected]) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"Hasta la Vista, Abie!"
- Bart Simpson

 

[Dave Vandervies]

[PJP's article didn't show up on my server yet, hence the (partial)
piggy-backing.]

I haven't seen ANY of his messages, but lots of replies to them. Not
sure what's up with that.

The same happened to me. What's with this thing? What do news servers
have against Plauger?

Perhaps something his newsreader or server is doing is producing malformed
headers that some servers are dropping?

trn is displaying the followups to his posts as orphaned articles, and
not the normal "I know there should be an article here, but I can't find
it" entry in the thread display[1], which leads me to suspect something
wrong with the References header as a first guess.

Can anybody who can see his posts comment on this?

Perhaps we should make a poll about who can see
his messages and who can't.

I can't.


dave

[1] trn normally shows you something like this at the top of an article:
(1)+-(1)--(1)
\-(1)+-(1)--(2)
\-[1]
where the various bits of the display give information about
references, subject lines, and whether an article has been read.
Normally for a nonexistent article whose existence is inferred from
other clues (such as a Message-ID appearing in a followup's References
header) it will display the article without the number: "( )", while
the followups to Plauger's posts appear in a new left-hand entry,
indicating a common subject line but no known parents.

--
Dave Vandervies (e-mail address removed)

My goodness, how dry the British sense of humor is.

It's to compensate for our traditional weather.
--Dann Corbit and Chris Dollin in comp.lang.c

 

[Mike Wahler]

[PJP's article didn't show up on my server yet, hence the (partial)
piggy-backing.]

I haven't seen ANY of his messages, but lots of replies to them. Not
sure what's up with that.

I don't see them either. Perhaps a major trunk is down,
and only servers in a paritcular physical region are getting
them? I'm no networking expert, just a thought.

-Mike

 

[Sheldon Simms]

Default User <[email protected]> scribbled the following:

Richard Heathfield wrote:
[PJP's article didn't show up on my server yet, hence the (partial)
piggy-backing.]

I haven't seen ANY of his messages, but lots of replies to them. Not
sure what's up with that.

The same happened to me. What's with this thing? What do news servers
have against Plauger?

Perhaps something his newsreader or server is doing is producing malformed
headers that some servers are dropping?

trn is displaying the followups to his posts as orphaned articles, and
not the normal "I know there should be an article here, but I can't find
it" entry in the thread display[1], which leads me to suspect something
wrong with the References header as a first guess.

Can anybody who can see his posts comment on this?

I can't comment, but here are some headers:

Date: Tue, 7 Oct 2003 10:21:07 -0400
From: "P.J. Plauger" <[email protected]>
Lines: 50
Message-ID: <3f82cbd4$0$7587$afc38c87@>
NNTP-Posting-Host: 63.102.52.148
Newsgroups: comp.lang.c
Path: sn-us!sn-xit-04!sn-xit-06!sn-xit-08!supernews.com!news-out.visi.com!petbe.visi.com!ash.uu.net!spool.news.uu.net!not-for-mail
References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]>
Subject: Re: [OT] Compile C Code With A CPP Compiler?
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
X-Priority: 3
X-Trace: 1065536468 7587 63.102.52.148
Xref: sn-us comp.lang.c:670030
MIME-Version: 1.0
Content-Type: text/plain

 

[E. Robert Tisdale]

I don't see them either.

Did you check your killfile?

 

[Dave Vandervies]

[Posted and mailed to (e-mail address removed)]

Default User <[email protected]> scribbled the following:
Richard Heathfield wrote:
[PJP's article didn't show up on my server yet, hence the (partial)
piggy-backing.]

I haven't seen ANY of his messages, but lots of replies to them. Not
sure what's up with that.

The same happened to me. What's with this thing? What do news servers
have against Plauger?

Perhaps something his newsreader or server is doing is producing malformed
headers that some servers are dropping?

trn is displaying the followups to his posts as orphaned articles, and
not the normal "I know there should be an article here, but I can't find
it" entry in the thread display[1], which leads me to suspect something
wrong with the References header as a first guess.

Can anybody who can see his posts comment on this?

I can't comment, but here are some headers:

Date: Tue, 7 Oct 2003 10:21:07 -0400
From: "P.J. Plauger" <[email protected]>
Lines: 50
Message-ID: <3f82cbd4$0$7587$afc38c87@>

^^
<snip rest of headers>

That Message-ID isn't in the normal form <unique-identifier@host> - it's
missing the "host" part. I'm not sure whether it's actually considered
a malformed Message-ID or whether the servers that are dropping it are
broken[1], but in any case it seems to be rather antisocial behavior on
the part of whatever is assigning them.

In the time-honored usenet tradition of making unwarrantedly definite
statements from vague or nonexistent evidence, I'm going to suggest that
perhaps the host that's being used to post the articles doesn't have a
hostname configured and that's what's breaking the Message-ID.

'Tmight be a good idea to find the person responsible and arrange for
a hostname to be set.


dave

[1] The best I could come up with is from section 2.1.7 of RFC 850:
--------
Message ID's have the syntax

"<" "string not containing blank or >" ">"

In order to conform to RFC 822, the Message-ID must have
the format

"<" "unique" "@" "full domain name" ">"

where "full domain name" is the full name of the host at
which the article entered the network, including a domain
that host is in [...]
--------
Without reading anything beyond the immediate context, it's not clear
whether conformance to RFC822 (which requires the unique@host form)
is a requirement.

--
Dave Vandervies (e-mail address removed)

My goodness, how dry the British sense of humor is.

It's to compensate for our traditional weather.
--Dann Corbit and Chris Dollin in comp.lang.c