Compile C Code With A CPP Compiler?

[entropy123]

Hey all,

I'm working with some legacy C code and I would like to compile it as
a CPP file.

I get the following error message:

driver.cpp:87: cannot convert `void *' to `GenericStruct *' in
assignment

Reading through the web I've come across vague references to the
'void' issue between C and C++, I don't know C++ well and would
appreciate any pointers or references which might help me out.

Thanks!

entropy

[Mark A. Odell]

em**************@yahoo.com (entropy123) wrote in
news:90**************************@posting.google.c om:

I'm working with some legacy C code and I would like to compile it as
a CPP file.
To what end?
I get the following error message:

driver.cpp:87: cannot convert `void *' to `GenericStruct *' in
assignment
I believe C++ requires explicit casts on void pointers, you might ask this
in C++.
Reading through the web I've come across vague references to the
'void' issue between C and C++, I don't know C++ well and would
appreciate any pointers or references which might help me out.

Two approaches: (1) after finding out the C++ appropriate method of
converting void pointers to other types, fix-up all such conversions with
casts, (2) off-topic but you might find that there is a compiler override
switch to force the C++ compiler to theat a .cpp file as a .c file.

The latter has the benefit of allowing you to use one compiler for both
your C and C++ sources but won't allow you to add C++ features to said
files.

I'm not sure what benefit compiling a true C file as a .cpp file with a
C++ compiler will give you. Oddly enough, I have had to do that on my
current procject because it was once thought we'd convert drivers to C++.
Hence, I have told our compiler (Diab) to treat my .cpp files as .c files.
I've also wrapped the contents of the entire file with:

#ifdef __cplusplus
extern "C" {
#endif

/* File */

#ifdef __cplusplus
}
#endif

--
- Mark ->
--

[dis]

"entropy123" <em**************@yahoo.com> wrote in message
news:90**************************@posting.google.c om...

Hey all,

I'm working with some legacy C code and I would like to compile it as
a CPP file.

I get the following error message:

driver.cpp:87: cannot convert `void *' to `GenericStruct *' in
assignment

Reading through the web I've come across vague references to the
'void' issue between C and C++, I don't know C++ well and would
appreciate any pointers or references which might help me out.

Your c++ related question is best answered in one of the c++ specific
newsgroups, e.g. comp.lang.c++.

[OT] Without seeing the actual code, my best guess would be that you need to
cast the expression of type void* to type GenericStruct*, as no implicit
conversion from void* to GenericStruct* exists under C++. [/OT]

[Mike Wahler]

"entropy123" <em**************@yahoo.com> wrote in message
news:90**************************@posting.google.c om...

Hey all,

I'm working with some legacy C code and I would like to compile it as
a CPP file.
'CPP file' is not a concept defined by either the
C or C++ languages. Did you mean you wanted to
translate a file originally written in C with
a C++ compiler? This causes me to ask, why?

Note that some C constructs
are not valid in C++, and vice versa.

Also note that C++ is not topical here.
I get the following error message:

driver.cpp:87: cannot convert `void *' to `GenericStruct *' in
assignment
This is a valid diagnostic for a C++ program, but not
for a C program.
Reading through the web I've come across vague references to the
'void' issue between C and C++,
You cannot learn either language, or the differences,
by surfing the web. You need books.
I don't know C++ well
Books! :-)
and would
appreciate any pointers or references which might help me out.

I point and refer you to C++ books:
http://www.accu.org/bookreviews/publ...nner_s_c__.htm

and address your immediate problem:

C allows the conversion of 'void*' to and from any
other pointer type without a cast. C++ requires
a cast. (I'm guessing this is happening with an
invocation of 'malloc()')

#include <stdlib.h>

int main()
{
struct GenericStruct
{
/* whatever */
} the_data;

GenericStruct* gsp = (GenericStruct*)malloc(sizeof the_data);
/* whatever */
free((void*)gsp);
return 0;
}

Further discussions about this belong in a C++ group,
or the 'alt.comp.lang.learn.c-c++' group, where both
langs are topical.

Followups set.

-Mike

[Dan Pop]

In <90**************************@posting.google.com > em**************@yahoo.com (entropy123) writes:

I'm working with some legacy C code and I would like to compile it as
a CPP file.
This is a brain dead idea, unless you're both a C and C++ expert and you
know perfectly well what you're doing.
I get the following error message:

driver.cpp:87: cannot convert `void *' to `GenericStruct *' in
assignment

Reading through the web I've come across vague references to the
'void' issue between C and C++, I don't know C++ well and would
appreciate any pointers or references which might help me out.

1. By what kind of logic have you decided that comp.lang.c is the right
place for asking C++ questions? Do you also post your C questions to
comp.lang.c++ ? ;-)

2. If you don't know C++ well, you don't use a C++ compiler (except for
C++ learning purposes).

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[entropy123]

Thanks for the replies. I spent all summer with C and I'm just
starting to learn C++. The idea with the legacy code is to convert it
from C/bison to C++. Most of the SRC files are written in "C" as well
as the driver. I was thinking if the driver is compiled in C++ then I
could start writing additional code in C++ without worry.

As I understand the situation, C programs may be compiled as C++, but
generally not the other way around.

Inasmuch as the replies involved C++ language I have no clue, but I do
own D&Ds C++ book which I've found excellent at least through the
first 100 easy pages..

Sorry for being OT.

entropy

[Dan Pop]

In <90**************************@posting.google.com > em**************@yahoo.com (entropy123) writes:

As I understand the situation, C programs may be compiled as C++, but
generally not the other way around.

Your understanding is completely wrong. If you know what you're doing,
it is possible to write C programs that can be compiled with C++
compilers, but a well written, non-trivial C program is highly unlikely
to be acceptable to a C++ compiler.

C and C++ have a common subset. It doesn't make much sense to write
programs using only this common subset: they would be considered as
badly written from both the C and C++ point of view.

Until you *fully* understand these issues, don't try to compile C code
with a C++ compiler, unless you love shooting yourself in the foot.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Mike Wahler]

"entropy123" <em**************@yahoo.com> wrote in message
news:90**************************@posting.google.c om...

Thanks for the replies. I spent all summer with C and I'm just
starting to learn C++. The idea with the legacy code is to convert it
from C/bison to C++.
Again, why? If you're wanting to learn C++, the best
way imo is to write your C++ programs from scratch.
C and C++ syntax is similar enough, but the behavior
of each is (often subtly) different enough, that what
you're attempting will not only prevent learning,
but cause you to 'learn' things which are not correct.
Most of the SRC files are written in "C" as well
as the driver. I was thinking if the driver is compiled in C++ then I
could start writing additional code in C++ without worry.
What has that to do with the C code?

As I understand the situation, C programs may be compiled as C++, but
generally not the other way around.
Then you don't understand. See Dan's reply.

Inasmuch as the replies involved C++ language I have no clue,
And you should not expect anyone here to have any 'clues'
about C++ either. This group is about C. Some folks here,
including myself, have at least some understanding of C++,
but we don't discuss it here, as I pointed out in my previous
reply. I also referred you to a group where both languages
*are* topical.
but I do
own D&Ds C++ book which I've found excellent at least through the
first 100 easy pages..
I think that's a pretty decent book, although there are others
I consider superior (it's a good idea to have more than one
book about a subject you're learning anyway).

Sorry for being OT.

Here's the link to info telling what the topic here is:
http://www.angelfire.com/ms3/bchambl...me_to_clc.html

The C++ groups have similar documents, check them out
before posting there, either. You can find these documents
by perusing the posts in those groups. Links to them
are posted periodically, and are contained in the .sigs
of some of the regulars.
-Mike

[entropy123]

"Mike Wahler" <mk******@mkwahler.net> wrote in message news:<oYDeb.11339

Again, why? If you're wanting to learn C++, the best
way imo is to write your C++ programs from scratch.
Agreed, but the project relies upon about 10 years worth of legacy 'C'
code. I've been working in C, and, after a few conversations, decided
C++ is a better longterm decision for the code.

'main' is in a *.c file with approximately 15 subordinate *.c files.
My understanding is that 'C' will compile just fine in 'C++' but not
vice versa. As it looks like C++ will be a better programming language
for this project I need to start moving the legacy 'C' code to 'C++'.

If the changes to the *.c driver are small it will all be worth it, if
not...
Most of the SRC files are written in "C" as well

as the driver. I was thinking if the driver is compiled in C++ then I
could start writing additional code in C++ without worry.

What has that to do with the C code?

As I understand the situation, C programs may be compiled as C++, but
generally not the other way around.

Then you don't understand. See Dan's reply.

Inasmuch as the replies involved C++ language I have no clue,

And you should not expect anyone here to have any 'clues'
about C++ either. This group is about C. Some folks here,
including myself, have at least some understanding of C++,
but we don't discuss it here, as I pointed out in my previous
reply. I also referred you to a group where both languages
*are* topical.

but I do
own D&Ds C++ book which I've found excellent at least through the
first 100 easy pages..

I think that's a pretty decent book, although there are others
I consider superior (it's a good idea to have more than one
book about a subject you're learning anyway).

Sorry for being OT.

Here's the link to info telling what the topic here is:
http://www.angelfire.com/ms3/bchambl...me_to_clc.html

The C++ groups have similar documents, check them out
before posting there, either. You can find these documents
by perusing the posts in those groups. Links to them
are posted periodically, and are contained in the .sigs
of some of the regulars.
-Mike

[Mark A. Odell]

em**************@yahoo.com (entropy123) wrote in
news:90**************************@posting.google.c om:

My understanding is that 'C' will compile just fine in 'C++' but not
vice versa.

Not true. All your variables with names like 'new', 'class', etc. will
cause syntax errors.

--
- Mark ->
--

[Mike Wahler]

"entropy123" <em**************@yahoo.com> wrote in message
news:90**************************@posting.google.c om...

"Mike Wahler" <mk******@mkwahler.net> wrote in message news:<oYDeb.11339

Again, why? If you're wanting to learn C++, the best
way imo is to write your C++ programs from scratch.
Agreed, but the project relies upon about 10 years worth of legacy 'C'
code. I've been working in C, and, after a few conversations, decided
C++ is a better longterm decision for the code.

It's still often (but perhaps not always) a better idea
to rewrite the whole thing. Many C idioms don't translate
well into well designed C++. A 'direct' translation of
existing algorithms could even concievably reduce, not
enhance code quality, maintainability, readability, etc.

'main' is in a *.c file with approximately 15 subordinate *.c files.
My understanding is that 'C' will compile just fine in 'C++'
You've already been told by me and Dan (who I feel has
considerable more knowledge than I) that that 'understanding'
is unfounded.
but not
vice versa. As it looks like C++ will be a better programming language
for this project
Upon what do you base this conclusion? I'm not saying
it's a poor conclusion, but be sure you have valid
premises.
I need to start moving the legacy 'C' code to 'C++'.
I recommend you first identify valid premises for this
conclusion. You could easily wind up doing much
unnecessary (and possibly even harmful) work.


If the changes to the *.c driver are small it will all be worth it,
Ease of translation is imo no justification of the 'worth'
of such a translation.
if
not...
"if". Hmmm. Find out for sure.

> Most of the SRC files are written in "C" as well

as the driver. I was thinking if the driver is compiled in C++

.... you might be doing unnecessary work.

then I could start writing additional code in C++ without worry.

IMO that's a very naive conclusion.

-Mike

[Chris Torek]

In article <90**************************@posting.google.com >
entropy123 <em**************@yahoo.com> writes:

My understanding is that 'C' will compile just fine in 'C++' but not
vice versa.

Aside from the obvious problems with identifiers in C that are
keywords in C++ (such as "new" and "virtual"), try compiling
the following as C, then again as C++:

#include <stdio.h>

#define MAX 10

struct A {
int n;
struct A_stats {
int in, out;
} stats[MAX];
};

void printstat(struct A_stats *p) {
printf("%d in, %d out\n", p->in, p->out);
}

void print_all_stats(struct A *p) {
int i;

for (i = 0; i < p->n; i++)
printstat(&p->stats[i]);
}

The scoping here, which makes this valid C code and invalid C++,
is one of the more subtle differences between C and C++. With care
-- or by a particularly (un?)lucky accident -- it can be used to
create code that compiles in both languages, yet has completely
different semantics.
--
In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.

[pete]

entropy123 wrote:

As I understand the situation, C programs may be compiled as C++,
but generally not the other way around.

If you have both kinds of compilers,
then this is two different programs:

/* BEGIN new.c or new.cpp */

#include <stdio.h>

char foo;

int main(void)
{
struct foo {
char a[2];
};

if (sizeof (foo) == 1) {
puts("\nC mode");
} else {
puts("\nC++ mode");
}
return 0;
}

/* END new.c or new.cpp */

--
pete

[goose]

Chris Torek <no****@elf.eng.bsdi.com> wrote in message news:<bl**********@elf.eng.bsdi.com>...

In article <90**************************@posting.google.com >
entropy123 <em**************@yahoo.com> writes:

My understanding is that 'C' will compile just fine in 'C++' but not
vice versa.

Aside from the obvious problems with identifiers in C that are
keywords in C++ (such as "new" and "virtual"), try compiling
the following as C, then again as C++:

#include <stdio.h>

#define MAX 10

struct A {
int n;
struct A_stats {
int in, out;
} stats[MAX];
};

void printstat(struct A_stats *p) {
printf("%d in, %d out\n", p->in, p->out);
}

void print_all_stats(struct A *p) {
int i;

for (i = 0; i < p->n; i++)
printstat(&p->stats[i]);
}

The scoping here, which makes this valid C code and invalid C++,
is one of the more subtle differences between C and C++. With care
-- or by a particularly (un?)lucky accident -- it can be used to
create code that compiles in both languages, yet has completely
different semantics.

even worse, iirc the OP said something about writing "drivers" ?
in that case, using C++ presents yet another problem ... default
exception handling code is generated for constructors/destructors.

in which case just having something like

class foo_t a { ... }

....
foo_t bar;
....
generates code that the programmer does not even see ...

goose

[entropy123]

Hmmm,

Well thank you all for the advice. I've decided to wait until I know
more C++ to decide whether or not to make the change. My colleagues
believe Templates and Vectors alone will make the change worthwhile,
but they do not work directly with this code...and I don't know C++
yet...

Thanks,
entropy

[Mike Wahler]

"entropy123" <em**************@yahoo.com> wrote in message
news:90**************************@posting.google.c om...

Hmmm,

Well thank you all for the advice. I've decided to wait until I know
more C++ to decide whether or not to make the change. My colleagues
believe Templates and Vectors alone will make the change worthwhile,
but they do not work directly with this code...and I don't know C++
yet...

IMO about the only thing which would make the change "worthwhile"
is if the application *design* is better suited to the new language.
In which case, a "write from scratch" approach could still be the
best route. Don't be afraid of a "total rewrite", my experience
has been that even when done in the same language, the result is
usually better than the original.

-Mike

[Micah Cowan]

em**************@yahoo.com (entropy123) writes:

"Mike Wahler" <mk******@mkwahler.net> wrote in message news:<oYDeb.11339

Again, why? If you're wanting to learn C++, the best
way imo is to write your C++ programs from scratch.

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

'main' is in a *.c file with approximately 15 subordinate *.c files.
My understanding is that 'C' will compile just fine in 'C++' but not
vice versa.

This is a fallacy, as you are discovering. There are many C
programs which will fail to compile in C++. And, as it turns out,
idiomatically "correct" C code will especially tend not to
compile in C++ (for example, casting void*).

I'd highly recommend compiling the C code as C code, since you
can easily *link* to the results from C++ object code (this
ability is specified by the C++ standard; the C standard has no
knowledge of C++).

-Micah

[CBFalconer]

Micah Cowan wrote:

.... snip ...
I'd highly recommend compiling the C code as C code, since you
can easily *link* to the results from C++ object code (this
ability is specified by the C++ standard; the C standard has no
knowledge of C++).

Not quite. No C compiler or program is allowed to define
__cplusplus__ thus allowing the ubiquitious wrapper:

#ifdef __cplusplus__
#extern 'C' {
#endif
....
#ifdef __cplusplus__
}
#endif

to allow .h files to be used in C++ code and generate the correct
links.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Peter Nilsson]

"CBFalconer" <cb********@yahoo.com> wrote in message
news:3F***************@yahoo.com...

Micah Cowan wrote:

... snip ...

I'd highly recommend compiling the C code as C code, since you
can easily *link* to the results from C++ object code (this
ability is specified by the C++ standard; the C standard has no
knowledge of C++).

Not quite. No C compiler or program is allowed to define
__cplusplus__

^^
No C99 implementation will define __cplusplus, but AFAIK C90 implementations
are not constrained in that regard.

--
Peter

[Dan Pop]

In <3f******@news.rivernet.com.au> "Peter Nilsson" <ai***@acay.com.au> writes:

"CBFalconer" <cb********@yahoo.com> wrote in message
news:3F***************@yahoo.com...

Micah Cowan wrote:

>

... snip ...

>
> I'd highly recommend compiling the C code as C code, since you
> can easily *link* to the results from C++ object code (this
> ability is specified by the C++ standard; the C standard has no
> knowledge of C++).

Not quite. No C compiler or program is allowed to define
__cplusplus__

^^
No C99 implementation will define __cplusplus, but AFAIK C90 implementations
are not constrained in that regard.

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

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[CBFalconer]

Dan Pop wrote:

"Peter Nilsson" <ai***@acay.com.au> writes:

.... snip ...

No C99 implementation will define __cplusplus, but AFAIK C90
implementations are not constrained in that regard.

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.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Dan Pop]

In <3F***************@yahoo.com> CBFalconer <cb********@yahoo.com> writes:

Dan Pop wrote:

"Peter Nilsson" <ai***@acay.com.au> writes:

... snip ...

>
> No C99 implementation will define __cplusplus, but AFAIK C90
> implementations are not constrained in that regard.

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.

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[E. Robert Tisdale]

entropy123 wrote:

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>

[Micah Cowan]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:

entropy123 wrote:

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.

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]

"E. Robert Tisdale" wrote:

Correct. The future of C is C++.

I see Trollsdale is at it again.

Brian Rodenborn

[E. Robert Tisdale]

Micah Cowan wrote:

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]

"E. Robert Tisdale" wrote:

entropy123 wrote:

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.

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.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Richard Heathfield]

E. Robert Tisdale wrote:

Micah Cowan wrote:

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!

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 : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Richard Heathfield]

E. Robert Tisdale wrote:

entropy123 wrote:

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++.

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.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Micah Cowan]

"P.J. Plauger" <pj*@dinkumware.com> writes:

"Micah Cowan" <mi***@cowan.name> wrote in message news:m3************@localhost.localdomain...

In C, the way to avoid important errors when allocating memory is
to not cast malloc()'s return.

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?

Naturally, the error of having failed to #include <stdlib.h>,
thus getting an implied but incorrect function declaration.

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.

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.

And even in the current version of C++,
that method of inclusion will pollute the global namespace, which
is less-than-undesirable.

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]

"P.J. Plauger" <pj*@dinkumware.com> wrote:

"Micah Cowan" <mi***@cowan.name> wrote in message news:m3************@localhost.localdomain...

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.

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]

"P.J. Plauger" <pj*@dinkumware.com> wrote:

"Richard Heathfield" <do******@address.co.uk.invalid> wrote in message
news:bl**********@hercules.btinternet.com...

int* p = (int*)malloc(n*sizeof(int));
Typical Tisdale nonsense.

Mine too.

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

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++.

All code should either do something good or stop something bad from
happening.

Where does that leave comments?

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

Your cast does neither.

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.]

Richard Bos wrote:

"P.J. Plauger" <pj*@dinkumware.com> wrote:

"Richard Heathfield" <do******@address.co.uk.invalid> wrote in message
news:bl**********@hercules.btinternet.com...

> > int* p = (int*)malloc(n*sizeof(int));
>
> Typical Tisdale nonsense.
Mine too.

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

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++.

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.

> All code should either do something good or stop something bad from
> happening.

Where does that leave comments?

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

Right.

> Your cast does neither.
But it does reassure the reader that you know what kind of storage
you're trying to allocate.
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.
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.)

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).

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.

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".

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Default User]

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.


Brian Rodenborn

[Joona I Palaste]

Default User <fi********@company.com> 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 we should make a poll about who can see
his messages and who can't.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ---------------------------\
| 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]

In article <bl**********@oravannahka.helsinki.fi>,
Joona I Palaste <pa*****@cc.helsinki.fi> wrote:

Default User <fi********@company.com> 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?

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 dj******@csclub.uwaterloo.ca 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]

"Default User" <fi********@company.com> wrote in message
news:3F***************@company.com...

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.

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]

On Tue, 07 Oct 2003 20:11:28 +0000, Dave Vandervies wrote:

In article <bl**********@oravannahka.helsinki.fi>,
Joona I Palaste <pa*****@cc.helsinki.fi> wrote:

Default User <fi********@company.com> 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" <pj*@dinkumware.com>
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: <90**************************@posting.google.com > <EJ*****************@newsread4.news.pas.earthlink. net> <90**************************@posting.google.com > <oY******************@newsread3.news.pas.earthlink .net> <90**************************@posting.google.com > <3F**************@jpl.nasa.gov> <bl**********@hercules.btinternet.com>
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]

Mike Wahler wrote:

Default User wrote:

Richard Heathfield wrote:

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.

Did you check your killfile?

[Dave Vandervies]

[Posted and mailed to pj*@dinkumware.com]

In article <pa****************************@yahoo.com>,
Sheldon Simms <sh**********@yahoo.com> wrote:

On Tue, 07 Oct 2003 20:11:28 +0000, Dave Vandervies wrote:

In article <bl**********@oravannahka.helsinki.fi>,
Joona I Palaste <pa*****@cc.helsinki.fi> wrote:

Default User <fi********@company.com> 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" <pj*@dinkumware.com>
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 dj******@csclub.uwaterloo.ca 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

[Mark McIntyre]

On Mon, 6 Oct 2003 21:42:56 -0400, in comp.lang.c , "P.J. Plauger"
<pj*@dinkumware.com> wrote:

"Micah Cowan" <mi***@cowan.name> wrote in message news:m3************@localhost.localdomain...

In C, the way to avoid important errors when allocating memory is
to not cast malloc()'s return.

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?

We all know the error, but more to the point, what (apart from C++
compatibility) do you *gain* from it? IMHO it merely increases the
amount of maintenance you have to do. And what are you doing using
malloc in C++ anyway?

PJ we all know your reputation, and surely bow to it. But EXCEPT when
deliberately trying to generate code that compiles as both C and C++
(which frankly I think is fraught with serious danger), can you think
of a reason to do this? I can't.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>

[Mark McIntyre]

On Mon, 6 Oct 2003 21:49:09 -0400, in comp.lang.c , "P.J. Plauger"
<pj*@dinkumware.com> wrote:

"CBFalconer" <cb********@yahoo.com> wrote in message news:3F***************@yahoo.com...

"E. Robert Tisdale" wrote:

> int* p = (int*)malloc(n*sizeof(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.

Sorry, but the reason is to excellent for me to grasp. Me and my
pet camel find this to be quite sensible code.

I believe you've been hanging around here long enough to know
perfectly well what are the objections. You're trolling.... :-)

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>

[Default User]

"E. Robert Tisdale" wrote:

Mike Wahler wrote:

Default User wrote:

Richard Heathfield wrote:

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.

Did you check your killfile?

Trust me Trollsdale, if you aren't in it, Plauger certainly isn't.

Brian Rodenborn

[Default User]

Mike Wahler wrote:

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.

Google doesn't have them either. Elsethread speculation is malformed
headers. Other Plauger messages are showing up on google.


Brian Rodenborn

[Mark McIntyre]

On Tue, 7 Oct 2003 10:21:07 -0400, in comp.lang.c , "P.J. Plauger"
<pj*@dinkumware.com> wrote:

"Richard Heathfield" <do******@address.co.uk.invalid> wrote in message
news:bl**********@hercules.btinternet.com...

All code should either do something good or stop something bad from
happening.
Where does that leave comments?

in the "do something good or stop something bad from happening"
bracket or deleted during the review phase.
Examples
// don't delete this, it forces the fscking stoopid linker to include
// floating point maths
double d = 12.456;

// munge the frobozz into a tweedle, if and only if the
// morple was less than two twips beyond the flunge
z = foobar( x? y ? z? q? a: b: c: d:e, mu, zork->dwibble->gloink);

But they're not code anyway, they're whitespace. :-)

Your cast does neither.

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

And do you therefore cast all assignments?
int p;
p = (int) 11; // to reassure idiots that we know what type p has

Ludicrous example of course, but you get the point I'm sure.
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.

Meanwhile the CLC method requires neither change nor the diagnostic,
since by magic it all fixes itself. Self maintaining code. My
favorite.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>

[Richard Bos]

"P.J. Plauger" <pj*@dinkumware.com> wrote:

"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:bl**********@oravannahka.helsinki.fi...

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.

I post using Reply Group in Outlook Express, through news.alterdial.uu.net.

Which would explain why I _am_ seeing them, since I'm on news.nl.net,
which is run by the Dutch branch of UUNet.

Richard

[Joona I Palaste]

Default User <fi********@boeing.com.invalid> scribbled the following:

"E. Robert Tisdale" wrote:

Mike Wahler wrote:

> Default User wrote:
>>Richard Heathfield wrote:
>>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.

Did you check your killfile?

Trust me Trollsdale, if you aren't in it, Plauger certainly isn't.

Trollsdale is in my killfile but Plauger isn't. I don't even have to
check it. Tin nicely shows whether it never got the message or it just
doesn't want to show it to me:

Original message Some author(1)
+-> Some other author(2)
| +-> Yet another author(3)
`-> Last author(4)

In this case the "`->" marks the last reply to a particular message
in a thread. Notice how there isn't one between (3) and (4) even
though (3) is a reply to (2). That's because the hypothetical author
of the second reply to (2) has been killfiled, just like Trollsdale.
If someone were to reply to Trollsdale, I mean the hypothetical
author, it would show up as:

Original message Some author(1)
+-> Some other author(2)
| +-> Yet another author(3)
| `-> Reply to killfiled author(6)
`-> Last author(4)

Which would show that (6) was a reply to an invisible message, not to
(3). This is what is happening with Trollsdale but it's not what's
happening with Plauger.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"It's time, it's time, it's time to dump the slime!"
- Dr. Dante

[Richard Bos]

Richard Heathfield <do******@address.co.uk.invalid> wrote:

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

Richard Bos wrote:

"P.J. Plauger" <pj*@dinkumware.com> wrote:

"Richard Heathfield" <do******@address.co.uk.invalid> wrote in message
news:bl**********@hercules.btinternet.com...

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

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++.

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.

I certainly respect him as well, which is why I'm surprised and dismayed
that he'd take your objection to such ludicrous extremes. I hadn't
expected this from him; he doesn't need straw men.

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).

It may not be a big deal, but the above _is_ clearer than the
alternative.
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.

I think this is the crux: Mr. Plauger supplies a market that most of us
have nothing to do with, and which probably has its own demands. Most of
us write programs for ourselves or for customers, with no need for it to
be compilable on both C and C++ compilers, and in those, more usual
circumstances, the cast is to be avoided.

Richard

[Dan Pop]

In <3F***************@company.com> Default User <fi********@company.com> writes:

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.

Neither have I, for quite a while: only replies to his posts.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <3f****************@news.nl.net> rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

I think this is the crux: Mr. Plauger supplies a market that most of us
have nothing to do with, and which probably has its own demands. Most of
us write programs for ourselves or for customers, with no need for it to
be compilable on both C and C++ compilers,

Since practically every C++ compiler is accompanied by a C compiler, I can
see no need for writing code that is compilable on both C and C++
compilers. C++ compilers have a *standard* mechanism for calling
functions compiled by a compatible C compiler.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de