f



Compile C Code With A CPP Compiler?

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
0
9/30/2003 6:57:57 PM
comp.lang.c 30656 articles. 5 followers. spinoza1111 (3246) is leader. Post Follow

52 Replies
1021 Views

Similar Articles

[PageSpeed] 10

email_entropy123@yahoo.com (entropy123) wrote in
news:90cdce37.0309301057.25d7506f@posting.google.com: 

> 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 ->
--
0
nospam243 (468)
9/30/2003 7:18:06 PM
"entropy123" <email_entropy123@yahoo.com> wrote in message
news:90cdce37.0309301057.25d7506f@posting.google.com...

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


0
dis (15)
9/30/2003 7:20:20 PM
"entropy123" <email_entropy123@yahoo.com> wrote in message
news:90cdce37.0309301057.25d7506f@posting.google.com...
> 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/public/reviews/0sb/beginner_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


0
mkwahler (3821)
9/30/2003 7:22:12 PM
In <90cdce37.0309301057.25d7506f@posting.google.com> email_entropy123@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: Dan.Pop@ifh.de
0
Dan.Pop (3615)
10/1/2003 12:08:58 PM
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
0
10/1/2003 1:28:32 PM
In <90cdce37.0310010528.38d8ff8c@posting.google.com> email_entropy123@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: Dan.Pop@ifh.de
0
Dan.Pop (3615)
10/1/2003 2:28:42 PM
"entropy123" <email_entropy123@yahoo.com> wrote in message
news:90cdce37.0310010528.38d8ff8c@posting.google.com...
> 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/bchambless0/welcome_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


0
mkwahler (3821)
10/1/2003 5:15:00 PM
"Mike Wahler" <mkwahler@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/bchambless0/welcome_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
0
10/2/2003 6:53:46 PM
email_entropy123@yahoo.com (entropy123) wrote in
news:90cdce37.0310021053.1c213e0e@posting.google.com: 

> 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 ->
--
0
nospam243 (468)
10/2/2003 7:04:09 PM
"entropy123" <email_entropy123@yahoo.com> wrote in message
news:90cdce37.0310021053.1c213e0e@posting.google.com...
> "Mike Wahler" <mkwahler@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


0
mkwahler (3821)
10/2/2003 8:27:18 PM
In article <90cdce37.0310021053.1c213e0e@posting.google.com>
entropy123 <email_entropy123@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)  +1 801 277 2603
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.
0
nospam240 (154)
10/2/2003 9:45:33 PM
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
0
pfiland (6613)
10/3/2003 10:04:57 AM
Chris Torek <nospam@elf.eng.bsdi.com> wrote in message news:<bli69t$30a$1@elf.eng.bsdi.com>...
> In article <90cdce37.0310021053.1c213e0e@posting.google.com>
> entropy123 <email_entropy123@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
0
ruse (722)
10/3/2003 2:24:52 PM
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
0
10/3/2003 2:47:03 PM
"entropy123" <email_entropy123@yahoo.com> wrote in message
news:90cdce37.0310030647.3d161b79@posting.google.com...
> 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


0
mkwahler (3821)
10/4/2003 1:55:38 AM
email_entropy123@yahoo.com (entropy123) writes:

> "Mike Wahler" <mkwahler@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
0
micah2 (555)
10/4/2003 11:08:10 PM
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 (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!


0
cbfalconer (19194)
10/5/2003 6:39:42 AM
"CBFalconer" <cbfalconer@yahoo.com> wrote in message
news:3F7FA798.53CBD811@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


0
airia (1802)
10/5/2003 11:12:35 AM
In <3f7ffca3@news.rivernet.com.au> "Peter Nilsson" <airia@acay.com.au> writes:

>"CBFalconer" <cbfalconer@yahoo.com> wrote in message
>news:3F7FA798.53CBD811@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: Dan.Pop@ifh.de
0
Dan.Pop (3615)
10/6/2003 2:04:28 PM
Dan Pop wrote:
> "Peter Nilsson" <airia@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 (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!


0
cbfalconer (19194)
10/6/2003 4:35:51 PM
In <3F818F92.6C171C4C@yahoo.com> CBFalconer <cbfalconer@yahoo.com> writes:

>Dan Pop wrote:
>> "Peter Nilsson" <airia@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: Dan.Pop@ifh.de
0
Dan.Pop (3615)
10/6/2003 5:28:49 PM
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.

0
10/6/2003 5:59:06 PM
"E. Robert Tisdale" <E.Robert.Tisdale@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
0
micah2 (555)
10/6/2003 8:34:08 PM
"E. Robert Tisdale" wrote:

> Correct.  The future of C is C++.


I see Trollsdale is at it again. 



Brian Rodenborn
0
first.last4 (288)
10/6/2003 9:22:29 PM
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.

0
10/6/2003 10:17:02 PM
"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 (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!


0
cbfalconer (19194)
10/7/2003 12:12:26 AM
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 : binary@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
0
dontmail (1886)
10/7/2003 3:31:40 AM
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 : binary@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
0
dontmail (1886)
10/7/2003 3:56:19 AM
"P.J. Plauger" <pjp@dinkumware.com> writes:

> "Micah Cowan" <micah@cowan.name> wrote in message news:m365j2ksvz.fsf@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
0
micah2 (555)
10/7/2003 5:18:32 AM
"P.J. Plauger" <pjp@dinkumware.com> wrote:

> "Micah Cowan" <micah@cowan.name> wrote in message news:m365j2ksvz.fsf@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
0
rlb (4118)
10/7/2003 7:42:54 AM
"P.J. Plauger" <pjp@dinkumware.com> wrote:

> "Richard Heathfield" <dontmail@address.co.uk.invalid> wrote in message
> news:bltdh3$6g5$1@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
0
rlb (4118)
10/7/2003 2:48:00 PM
[PJP's article didn't show up on my server yet, hence the (partial) 
piggy-backing.]

Richard Bos wrote:

> "P.J. Plauger" <pjp@dinkumware.com> wrote:
> 
>> "Richard Heathfield" <dontmail@address.co.uk.invalid> wrote in message
>> news:bltdh3$6g5$1@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 : binary@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
0
dontmail (1886)
10/7/2003 6:26:14 PM
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
0
first.last4 (288)
10/7/2003 7:28:13 PM
Default User <first.last@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 (palaste@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
0
palaste (2323)
10/7/2003 7:49:41 PM
In article <blv5cl$2e8$2@oravannahka.helsinki.fi>,
Joona I Palaste  <palaste@cc.helsinki.fi> wrote:
>Default User <first.last@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          dj3vande@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
0
dj3vande (669)
10/7/2003 8:11:28 PM
"Default User" <first.last@company.com> wrote in message
news:3F8313CD.5D2513A9@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


0
mkwahler (3821)
10/7/2003 8:49:45 PM
On Tue, 07 Oct 2003 20:11:28 +0000, Dave Vandervies wrote:

> In article <blv5cl$2e8$2@oravannahka.helsinki.fi>,
> Joona I Palaste  <palaste@cc.helsinki.fi> wrote:
>>Default User <first.last@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" <pjp@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:         <90cdce37.0309301057.25d7506f@posting.google.com> <EJkeb.9110$RW4.4140@newsread4.news.pas.earthlink.net> <90cdce37.0310010528.38d8ff8c@posting.google.com> <oYDeb.11339$NX3.7357@newsread3.news.pas.earthlink.net> <90cdce37.0310021053.1c213e0e@posting.google.com> <3F81AD6A.2090802@jpl.nasa.gov> <bltdh3$6g5$1@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

0
sheldonsimms (452)
10/7/2003 8:54:46 PM
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?

0
10/7/2003 8:56:17 PM
[Posted and mailed to pjp@dinkumware.com]

In article <pan.2003.10.07.20.54.45.492535@yahoo.com>,
Sheldon Simms  <sheldonsimms@yahoo.com> wrote:
>On Tue, 07 Oct 2003 20:11:28 +0000, Dave Vandervies wrote:
>
>> In article <blv5cl$2e8$2@oravannahka.helsinki.fi>,
>> Joona I Palaste  <palaste@cc.helsinki.fi> wrote:
>>>Default User <first.last@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" <pjp@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          dj3vande@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
0
dj3vande (669)
10/7/2003 9:15:42 PM
"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
0
first.last3 (701)
10/7/2003 9:55:15 PM
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
0
first.last3 (701)
10/7/2003 9:56:41 PM
On Mon, 6 Oct 2003 21:42:56 -0400, in comp.lang.c , "P.J. Plauger"
<pjp@dinkumware.com> wrote:

>"Micah Cowan" <micah@cowan.name> wrote in message news:m365j2ksvz.fsf@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>
0
markmcintyre (4555)
10/7/2003 10:06:17 PM
On Mon, 6 Oct 2003 21:49:09 -0400, in comp.lang.c , "P.J. Plauger"
<pjp@dinkumware.com> wrote:

>"CBFalconer" <cbfalconer@yahoo.com> wrote in message news:3F81E512.E8594D8A@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>
0
markmcintyre (4555)
10/7/2003 10:08:49 PM
On Tue, 7 Oct 2003 10:21:07 -0400, in comp.lang.c , "P.J. Plauger"
<pjp@dinkumware.com> wrote:

>"Richard Heathfield" <dontmail@address.co.uk.invalid> wrote in message
>news:bltdh3$6g5$1@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>
0
markmcintyre (4555)
10/7/2003 10:17:00 PM
"P.J. Plauger" <pjp@dinkumware.com> wrote:

> "Joona I Palaste" <palaste@cc.helsinki.fi> wrote in message
> news:blv5cl$2e8$2@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
0
rlb (4118)
10/8/2003 7:09:25 AM
Default User <first.last@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 (palaste@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
0
palaste (2323)
10/8/2003 7:39:49 AM
Richard Heathfield <dontmail@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" <pjp@dinkumware.com> wrote:
> > 
> >> "Richard Heathfield" <dontmail@address.co.uk.invalid> wrote in message
> >> news:bltdh3$6g5$1@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
0
rlb (4118)
10/8/2003 11:28:42 AM
In <3F8313CD.5D2513A9@company.com> Default User <first.last@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: Dan.Pop@ifh.de
0
Dan.Pop (3615)
10/8/2003 1:22:23 PM
In <3f83f3be.165100699@news.nl.net> rlb@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: Dan.Pop@ifh.de
0
Dan.Pop (3615)
10/8/2003 2:33:43 PM
Richard Bos wrote:
> "P.J. Plauger" <pjp@dinkumware.com> wrote:
> > "Joona I Palaste" <palaste@cc.helsinki.fi> wrote in message
> >
> > > 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.

Has anybody considered that the so-called original may well have
been a spoof.  After all, from all accounts it recommended an
unclean practice.  Someone somewhere may have detected the spoof
and killed it.

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


0
cbfalconer (19194)
10/8/2003 3:50:12 PM
Richard Bos wrote:

> Richard Heathfield <dontmail@address.co.uk.invalid> wrote:
> 
>> Richard Bos wrote:
>> 
>> > "P.J. Plauger" <pjp@dinkumware.com> wrote:
>> > 
>> >> 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.

I must admit that I was rather surprised, too. It is true that he is in a 
rather different market to the rest of us, of course, but I must admit I'm 
rather taken aback by his position here. I have been trying to think of a 
good reason why anyone as clueful (and lots of other positive adjectives) 
as PJP would want to follow such a strange policy. I didn't succeed.

-- 
Richard Heathfield : binary@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
0
dontmail (1886)
10/8/2003 7:50:55 PM
In article <bm132f$44n$11@sunnews.cern.ch>, Dan.Pop@cern.ch says...
> Neither have I, for quite a while: only replies to his posts.
> 
> Dan

Strange, I've been getting the entire thing... 

-- 
Randy Howard            _o     
2reply remove FOOBAR    \<,    
______________________()/ ()______________________________________________
SCO Spam-magnet: postmaster@sco.com
0
randy.howard (624)
10/9/2003 2:03:39 AM
Reply:

Similar Artilces:

program that compiles in C compiler but not in C++ compiler
Hi, I need a small program that compiles in C compiler but not in C++ compiler. Thx in advans, Karthik Balaguru KBG <karthik.balaguru@lntinfotech.com> wrote: > I need a small program that compiles in C compiler but not in C++ > compiler. No problem, just send $10 to paypal@zevv.nl and I'll do your homework for you. -- :wq ^X^Cy^K^X^C^C^C^C KBG said: > Hi, > > I need a small program that compiles in C compiler but not in C++ > compiler. Can you think of any syntactic differences between C and C++? For example, what about keywords? They are very, very sen...

compiling c code but libraries are compiled in c++
hi, We have written cunit code for testing some APIs. defination of those APIs are in c++ and .so library is created of them. when I compile my cunit code it gets compiled successfully but while liking it gives undefined reference to symbol. can anyone help me in this matter. Regards Sumit Shrivastava On 29 May 2007 04:11:14 -0700 sumit <sumit.shrivastava09@gmail.com> wrote: | We have written cunit code for testing some APIs. defination of | those APIs are in c++ and .so library is created of them. when I | compile my cunit code it gets compiled successf...

g++ compiled C++ code called from gcc compiled C code
Hi all! In a C library compiled with gcc there is a pointer to a function defined and called from within the library. Now I'm using that library in a C++ project and I'd like to set this function pointer to a C++ function. Do I have to set the C++ function __attribute__((cdecl)) ? Are there any other things I have to worry about? See example code below. Thanks very much, Klaus Example Code: ----------------------------------------------------- *** lib.c (compiled with gcc and linked to a library): void (* logfunc)(int,char*,...); int getSomething(void) { ... logf...

Are sun studio C/C++ compilers and Forte C/C++ compilers same ??
Is there any difference between sun studio compilers and forte compilers??? or the names have been changed??? In article <1145338052.955429.256610@v46g2000cwv.googlegroups.com>, "ameya_agnihotri" <ameyaagnihotri22@gmail.com> writes: > Is there any difference between sun studio compilers and forte > compilers??? > or the names have been changed??? One of many name changes in the product's history (including amongst others, Java somethingortheother, Workshop, Proworks/Teamworks, and probably more I've forgotten). Of course, the versions and features cha...

Cannot compile c/c++ code with Matlab R2009a Lcc compiler
Hello, I am using the lcc compiler in Matlab R2009a to create MEX files. The c/c++ files have previously been compiled and found to work in visual studio, but the matlab compiler appear to expect another syntax: class 'Sample.cpp': #include <stdio.h> #include <math.h> #include "mex.h" static const int nbrOfBands = 1; double FindShortestPath(double fromAngle, double toAngle); double FindShortestPath(double fromAngle, double toAngle, double scanDirection); double FindShortestPath(double fromAngle, double toAngle) { return findShortestPath(fro...

mex compiling c++ code but not c code
i get the following error when i try to compile the following code: //hello.c #include <mex.h> void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[]) { mexPrintf("Hello World!\n"); } / usr/local/MATLAB/R2012a/bin/mex: 1: eval: -c: not found mex: compile of ' "hello.c"' failed. Error using mex (line 206) Unable to complete successfully. when i use the same code but name it as hello.cpp it compiles fine & prints hello world. im using matlab 2012a,ubuntu 12.04,gcc-4.6,g++-4.6 my mex-opts.sh has C...

code that compiles in c but not in c++?
Hi,is there a code that can compile in c but not in c++ and does not use any c++ keywords as identifiers? I suspect using void* works in c but not in c++. Any suggestions? al.c...@gmail.com wrote: > Hi,is there a code that can compile in c but not in c++ and does not > use any c++ keywords as identifiers? Yes, there are plenty of examples, here is a simple one: int * iptr = malloc(10); /* Cast required in C++, frowned on in C */ C and C++ are two different languages and I wouldn't recommend trying to write code that works in both. However, if you need to know how to write C++ ...

Will C pgm compile on C++ compiler?
I had C programming in school years ago and would like to play with it again. When I go online I only seem to be able to find C++ compilers. I know that C++ is object oriented, whereas C is not. I can get a good price on Visual C++ 6.0. Is there a way to run native C programs on a C++ compiler? Thanks, Ken [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] "Ken Applequist" <apple07840@yahoo.com> wrote in message news:<Sh%1d.4320$F75.1229@trndny01>... > I had C programming in school ...

Could I compile "c" source with a C++ compiler (Forte C++ Update 2)?
Does Forte C++ Update 2 compiles C source code in ANSI C as same as Forte C udpate 2 does? Jacob, Park <bluejacob@empal.com> wrote: > Does Forte C++ Update 2 compiles C source code in ANSI C as same as > Forte C udpate 2 does? If you're asking whether "CC" will compile the same code as "cc", then the answer is no. This is true for ANY standard-compliant c++ compiler (compilers with different "language mode" like gcc don't count as a single compiler for this description). However, usually one can make C code "compilable" by C++ co...

Writing a C/C++ compiler in C++
I've been thinking of writing a C++ compiler in C++ over the next several years, and I was wondering what's changed in writing a compiler? I've been pouring over these groups and there seems to be a lot of tools for starting but is the modern process still the same? As far as I understand it you write a lexer that tokenizes all the symbols, then write a parser that parses all of the tokens, then walks the parse tree to generate the asm or IL that gets shoved to the backend. So it seemed straightforward except that C++ isn't a LALR(1) grammer that Bison or Byacc accepts. Does ...

Compiling IDL code with a C compiler
Hi everyone, I'm interested in writing an IDL-to-C compiler, for optimization purposes. To be clear about what I'm talking about, here's what some sample IDL code would look like: ;#COMPILE gcc -O1 function EvaluateEnergy, field, area ; Type Declarations ;#field = fltarr(101, 101) ;#area = fltarr(101, 101) ;#sum = float(0.) sum = 0 for x=0, 100 do begin for y=0, 100 do begin sum = sum + field[x,y] ^ 2 * area[x, y] endfor endfor return, sum end My IDL-to-C (pre)compiler would parse the IDL pro files, looking for functions preceded by a ;#COMPILE (aka ~preprocessor di...

How to compile this C Code in Dev-C++??
I have done the following: New Project -> Console Application -> C Project. Then I get the following text: #include <stdio.h> #include <stdlib.h> int main(int argc, char *argv[]) { system("PAUSE"); return 0; } But where do I write my own C code? I have written the following code: void c(unsigned int n) { while (n > 1) if ((n & 1) == 0) n = n/2; else n = 3 * n + 1; } But where should I put it and how do I compile it? js * JS: > I have done the following: New Project -> Console Application -> C Project. Off-topic on two groun...

Re: Will C pgm compile on C++ compiler?
Ken Applequist wrote: > I had C programming in school years ago and would like to play with it > again. When I go online I only seem to be able to find C++ compilers. I know > that C++ is object oriented, whereas C is not. I can get a good price on > Visual C++ 6.0. Is there a way to run native C programs on a C++ compiler? Several authors implied that a C++ compiler can compile C programs. This is only correct with some restrictions. For example, you can obviously not use C++ keywords as identifiers. For example, the following is a legal C program but will fail using C++: in...

commercial c compilers vs free c compilers
what are the benefits in using commercial compilers like intel, greenhill or portland compared to free c compiles like gcc, lcc, tcc, TenDRA, sun and others? geletine wrote: > what are the benefits in using commercial compilers like intel, > greenhill or portland compared to free c compiles like gcc, lcc, tcc, > TenDRA, sun and others? > <mostly non-topical> As we have no idea of your interests, potential benefits may not be meaningful in your projects. More than one of these commercial compilers is more efficient about vectorization, although gcc is closing the gap. <...

Web resources about - Compile C Code With A CPP Compiler? - comp.lang.c

Compiler - Wikipedia, the free encyclopedia
... , or external linking . The most common reason for wanting to transform source code is to create an executable program. The name "compiler" ...

Compiler - Wikipedia, the free encyclopedia
"Compile" and "compiling" redirect here. For the software company, see Compile (publisher) . For other uses, see Compilation . This article has ...

Facebook Open-Sources HipHop PHP Compiler Software
Earlier this morning, Facebook officially made their new PHP “compiler,” called HipHop, available as open source software. In the blog post by ...

Art in the Age of Matter Compilers
jurvetson posted a photo: Sheba may be the harbinger of art in the digital age — a mathematical sculptor with digital matter. She manipulates ...

Interpreters and Compilers (Bits and Bytes, Episode 6) - YouTube
This animation explains the difference between interpreters and compilers. It is from Episode 6 of the classic 1983 television series, Bits and ...

Typesafe cofounder forking Scala compiler
The main contributor to the Scala compiler, Paul Phillips, has announced on GitHub that he is forking the compiler to “fix some of the innumerable ...

Does Apple's new developer agreement ban Adobe's Flash-to-iPhone compiler?
Given that any kind of formal truce between Apple and Adobe was essentially blown out of the water by Steve Job's very public slating of Flash ...

Apple seeds devs with Safari 5.2 for Lion, Xcode 4.4 with new LLVM compiler
... to the general public this summer. Among the new features: According to Apple, Xcode 4.4 includes an editor for Collada 3D files, compiler support ...

NVIDIA and Continuum Analytics Announce NumbaPro, A Python CUDA Compiler
... are announcing that they are bringing Python support to CUDA. Specifically, Continuum Analytics’ will be introducing a new Python CUDA compiler, ...

IntelliJ Releases IDEA 12, Brings Improved UI, New Compiler Mode, Android UI Designer, And More
I'm not going to pretend to be a developer here, and I'll openly admit that the bulk of what IDEA 12 does is over my head. However, I do understand ...

Resources last updated: 2/8/2016 5:19:18 AM