f



Why would someone use c++ compiler on a C code?

Would it suppress errors?

Is he trying to hide errors in his code?
0
FW3006 (26)
4/8/2008 4:56:03 AM
comp.lang.c 30656 articles. 5 followers. spinoza1111 (3246) is leader. Post Follow

23 Replies
940 Views

Similar Articles

[PageSpeed] 43

On Apr 7, 9:56 pm, 2005 <FW3...@sbcglobal.net> wrote:
> Would it suppress errors?
>
> Is he trying to hide errors in his code?

He is using g++ on a *.c code!

Also what is so different between gcc & cc compiler - any advantages?
0
FW3006 (26)
4/8/2008 4:57:13 AM
2005 wrote:
> Would it suppress errors?
> 
> Is he trying to hide errors in his code?

Probably the reverse, C++ and its compilers are more pedantic about a
number of issues, particularly type safety.

Do bear in ming there are sometimes obscure semantic differences between
 the two languages, so you would be ill advised to try this at home
unless you are aware of the risks.

-- 
Ian Collins.
0
ian-news (10155)
4/8/2008 5:01:53 AM
On Apr 7, 10:01 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> 2005 wrote:
> > Would it suppress errors?
>
> > Is he trying to hide errors in his code?
>
> Probably the reverse, C++ and its compilers are more pedantic about a
> number of issues, particularly type safety.
>
> Do bear in ming there are sometimes obscure semantic differences between
>  the two languages, so you would be ill advised to try this at home
> unless you are aware of the risks.
>
> --
> Ian Collins.

I tried this code on "cc -c" - it gave numerous errors
But non when I did g++ on a C code

Is this a good practice to compile a C code with g++ compiler.
0
FW3006 (26)
4/8/2008 5:36:29 AM
2005 wrote:
> On Apr 7, 10:01 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>> 2005 wrote:
>>> Would it suppress errors?
>>> Is he trying to hide errors in his code?
>> Probably the reverse, C++ and its compilers are more pedantic about a
>> number of issues, particularly type safety.
>>
>> Do bear in ming there are sometimes obscure semantic differences between
>>  the two languages, so you would be ill advised to try this at home
>> unless you are aware of the risks.
>>
*Please* don't quote signatures.
> 
> I tried this code on "cc -c" - it gave numerous errors
> But non when I did g++ on a C code
> 
Then the code is more than likely C like C++, not C.

> Is this a good practice to compile a C code with g++ compiler.

Not unless you have a specific reason for doing so.

-- 
Ian Collins.
0
ian-news (10155)
4/8/2008 5:39:49 AM
In article 
<a46ea80c-3394-443b-bade-2f38f18273da@q27g2000prf.googlegroups.com>,
 2005 <FW3006@sbcglobal.net> wrote:

> Would it suppress errors?
> 
> Is he trying to hide errors in his code?

A C++ compiler *IS*, by definition, a C compiler. PLUS some stuff. And 
generally, it's even pickier than its "plain C" counterpart. So no, it's 
not likely to suppress errors. If anything, it's more likely to complain 
even MORE about errors than a "plain" C compiler would.

In general, unless you're trying to compile C++ code (in which case, a 
"plain C" compiler just can't cope) it really doesn't much matter if you 
use a "plain" C compiler, or a C++ compiler on a straight C source.

As far as GCC/g++ versus CC, GCC is the "Gnu" version of CC. Not 
necessarily any better or worse, just a different "flavor". They both 
end up doing the same thing, although they may accomplish it in 
different ways. As far as which is better, you'd have to go deep into 
the guts of both the compiler, and the code it produces, to make any 
meaningful call about that. As I said, they both do the same thing - 
Grind up C (or C++) source code and spit out ready-to-link binary files. 
One might spit out "better" binary files than the other for some kinds 
of code, while the other one spits out better binary files for another 
type of code. There's just *WAY* too many variables to flatly state that 
one is "better than" the other.

The most obvious advantages of the "Gnu" version are that it's (1) Free, 
and (2) Open Source. Average folks aren't going to care all that much 
about the "Open Source" part, but the "Free" concept makes it REALLY 
attractive...

-- 
Don Bruder - dakidd@sonic.net - If your "From:" address isn't on my whitelist,
or the subject of the message doesn't contain the exact text "PopperAndShadow"
somewhere, any message sent to this address will go in the garbage without my
ever knowing it arrived. Sorry... <http://www.sonic.net/~dakidd> for more info
0
dakidd (783)
4/8/2008 5:41:49 AM
2005 said:

<snip>
 
> Is this a good practice to compile a C code with g++ compiler.

C and C++ are different languages. The claim that a C++ compiler is a C 
compiler (elsethread) is false.

You can't compile C code with a C++ compiler. When you submit a program to 
a compiler, a decision must be made about which language rules are being 
used. If the compiler only understands one language, that is the decision 
it makes. Otherwise, you have to tell it (this is often done via file 
suffix information). And the compiler will believe you.

If you tell a compiler to translate a program according to C++ rules, then 
(assuming that to do so is within its capabilities) as far as the compiler 
is concerned the code *is* C++ code, even if it looks like COBOL or 
Malbolge. Or C, or Pascal, or Lithp. And if you tell a compiler to 
translate a program according to C rules, then to the compiler the program 
/is/ C.

Many people think that C++ is a superset of C (if we don't count sillies 
like keyword clashing). If you are one such person, I invite you to 
compile the following C program using a C++ compiler, whilst observing a 
few simple rules.

/* Please convert this program to C++ using the
 * following rules:
 *
 * 1) the program must remain a valid C program.
 * 2) you may refactor recursive main() - so I
 *    didn't bother to use one.
 * 3) you may rename identifiers, including function
 *    names, as long as doing so does not change the
 *    output of the program.
 * 4) you may add casts.
 * 5) you can't change the program in any other way.
 *    That means you can't add header files, you can't
 *    add keywords, you can't change or remove comments,
 *    and you can't add whitespace or anything else.
 * 6) I could have made this a lot harder!
 */

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

#define a(b) #b
#define SPACE ' '

int main(void)
{
  const char *asm = a(asm);
  const char *protected = a(protected);
  const char *using = a(using);
  const char *b[28] = {0};
  char title__of__the__program[81] =
    "C to C++ Translation\nONLY extra casts and renaming"
    " of variables are allowed.\n\n\n\n\n";
  auto i = strlen(protected) -
    (sizeof SPACE //* we need a space\
    in here somewhere */ sizeof (int
    ) + strlen(asm) + strlen(using));

  if(strcmp(asm, "asm") != 0 || strcmp(protected, "protected") != 0 ||
strcmp(using, "using") != 0)
  {
    puts("Error!");
    return EXIT_FAILURE;
  }

  b[0] = asm + 1;
  b[1] = b[0] - 1;
  b[2] = protected + 8;
  b[4] = b[2] - 8;
  b[5] = b[4] + 1;
  b[6] = b[5] + 1;
  b[7] = using + 4;
  b[8] = b[5];
  b[9] = b[0] - 1;
  b[10] = b[0] + 1;
  b[11] = b[10];
  b[12] = b[2] - 4;
  b[13] = b[12] - 3;
  b[14] = b[0];
  b[16] = b[2];
  b[17] = b[16] - 6;
  b[19] = b[7] - 1;
  b[20] = b[2] - 6;
  b[21] = b[20] + 1;
  b[23] = b[7] - 4;
  b[24] = b[23] + 1;
  b[25] = b[2] - 4;
  b[27] = b[25] + 1;

  printf("%.*s\n",
         (int)sizeof title__of__the__program,
         title__of__the__program);

  while(i < sizeof b / sizeof b[0])
  {
    if(b[i] != NULL)
    {
      if(i == sizeof(char) / sizeof SPACE ||
         i == sizeof b / sizeof b[0] - 1)
      {
        putchar(toupper((unsigned char)
                b[i][sizeof(char)/sizeof SPACE]));
      }
      else
      {
        putchar(tolower((unsigned char)
                b[i][sizeof(char)/sizeof SPACE]));
      }
    }
    else
    {
      putchar(SPACE);
    }
    i += strlen(protected) - (strlen(asm) + strlen(using));
  }

  putchar('.' * sizeof SPACE / sizeof(int));
  putchar('\n');

  return 0;

}

(Incidentally, this program also demonstrates that C99 isn't a superset of 
C90.)

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
0
rjh (10791)
4/8/2008 6:41:09 AM
Don Bruder wrote:
> In article 
> <a46ea80c-3394-443b-bade-2f38f18273da@q27g2000prf.googlegroups.com>,
>  2005 <FW3006@sbcglobal.net> wrote:
> 
>> Would it suppress errors?
>>
>> Is he trying to hide errors in his code?
> 
> A C++ compiler *IS*, by definition, a C compiler. PLUS some stuff. 

The above is complete nonsense.  It is unbelievable that someone who 
knows so little can write so much with a presumed air of authority. 
Until we see evidence that Don Bruder has learned something, it is safer 
to ignore him.  For example.

> In general, unless you're trying to compile C++ code (in which case, a 
> "plain C" compiler just can't cope) it really doesn't much matter if you 
> use a "plain" C compiler, or a C++ compiler on a straight C source.

this is obvious bullshit.
0
mambuhl (2203)
4/8/2008 7:31:37 AM
Don Bruder wrote:
> In article 
> <a46ea80c-3394-443b-bade-2f38f18273da@q27g2000prf.googlegroups.com>,
>  2005 <FW3006@sbcglobal.net> wrote:
> 
>> Would it suppress errors?
>>
>> Is he trying to hide errors in his code?
> 
> A C++ compiler *IS*, by definition, a C compiler. PLUS some stuff. And 
> generally, it's even pickier than its "plain C" counterpart. So no, it's 
> not likely to suppress errors. If anything, it's more likely to complain 
> even MORE about errors than a "plain" C compiler would.

This is not true.

#include <stdlib.h>
#include <stdio.h>
int main(void) {
   int *class = malloc(sizeof 'a');
   for (*class = 0; *class<10; (*class)++) {
      printf("C is not a subset of C++\n");
   }
   return 0;
}

The above program is valid C but invalid C++. There are at least three
problems:

* 'class' is not a valid identifier in C++
* 'void *' does not automatically convert to 'int *' in C++
* The character constant 'a' is of type int in C, but of type 'char' in
C++, and so the call to malloc may not allocate enough storage.

Although C++ is mostly a superset of C, these differences (especially
implicit void * conversion) mean that many C programs will not compile
as C++ without some modification.
0
pgp (246)
4/8/2008 7:40:32 AM
2005 wrote:
> Would it suppress errors?
> 
> Is he trying to hide errors in his code?

Please repeat your question in the body of your message; don't just ask
it in the subject.

Others have suggested some solutions. The FAQ question 20.27 "Is C++ a
superset of C? What are the differences between C and C++? Can I use a
C++ compiler to compile C code?" will probably help you as well. The FAQ
also links to a statement on the subject from Bjarne Stroustrup, the
creator of C++. You can find the FAQ at http://c-faq.com/

Philip
0
pgp (246)
4/8/2008 7:43:32 AM
Richard Heathfield wrote:
> 
> /* Please convert this program to C++ using the
>  * following rules:

I tried to compile it as C first at got:

"/tmp/x.c", line 34: warning: no explicit type given
"/tmp/x.c", line 37: syntax error before or at: )
"/tmp/x.c", line 81: warning: implicit function declaration: toupper
"/tmp/x.c", line 86: warning: implicit function declaration: tolower

> 
> (Incidentally, this program also demonstrates that C99 isn't a superset of 
> C90.)
> 
So after renaming identifiers, a C++ compiler gave similar errors:

"/tmp/x.c", line 33: Error: Cannot use const char[82] to initialize
char[81].
"/tmp/x.c", line 37: Error: Unexpected ")" -- Check for matching
parenthesis.
"/tmp/x.c", line 81: Error: The function "toupper" must have a prototype.
"/tmp/x.c", line 86: Error: The function "tolower" must have a prototype.

So what does this prove? C++ is closer to C99?  C90 isn't C or C++?

-- 
Ian Collins.
0
ian-news (10155)
4/8/2008 8:02:24 AM
Ian Collins said:

> Richard Heathfield wrote:
>> 
>> /* Please convert this program to C++ using the
>>  * following rules:
> 
> I tried to compile it as C first at got:
> 
> "/tmp/x.c", line 34: warning: no explicit type given
> "/tmp/x.c", line 37: syntax error before or at: )

A copyo, perhaps? It compiles just fine here, under the strictest set of 
flags I can summon up.

> "/tmp/x.c", line 81: warning: implicit function declaration: toupper
> "/tmp/x.c", line 86: warning: implicit function declaration: tolower

Neither of these diagnostic messages is mandatory: implicit int is legal in 
C...

>> 
>> (Incidentally, this program also demonstrates that C99 isn't a superset
>> of C90.)

....except, of course, when it isn't.

> So what does this prove? C++ is closer to C99?  C90 isn't C or C++?

It demonstrates what we already know - i.e. that C++ compilers can't 
compile C programs. It makes this very obvious. What is less obvious is 
that C++ compilers can't compile C programs *even when the program is 
valid C++*. That's because, if a C++ compiler is compiling it, it is by 
definition a C++ program - i.e. a program that is translated according to 
C++ rules. It might *also*, at another time or place, be a C program (i.e. 
a program that can be translated correctly according to C rules) - but 
when the C++ compiler has its teeth into it, it is not reasonable to call 
it anything other than a C++ program.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
0
rjh (10791)
4/8/2008 8:48:59 AM
Richard Heathfield wrote:
> Ian Collins said:
> 
>> Richard Heathfield wrote:
>>> /* Please convert this program to C++ using the
>>>  * following rules:
>> I tried to compile it as C first at got:
>>
>> "/tmp/x.c", line 34: warning: no explicit type given
>> "/tmp/x.c", line 37: syntax error before or at: )
> 
> A copyo, perhaps? It compiles just fine here, under the strictest set of 
> flags I can summon up.
> 
>> "/tmp/x.c", line 81: warning: implicit function declaration: toupper
>> "/tmp/x.c", line 86: warning: implicit function declaration: tolower
> 
> Neither of these diagnostic messages is mandatory: implicit int is legal in 
> C...
> 
Read them again "implicit function declaration".  Your forgot <ctype.h>

Implicit int is illegal in both C99 (C) and C++.

>>> (Incidentally, this program also demonstrates that C99 isn't a superset
>>> of C90.)
> 
> ....except, of course, when it isn't.
> 
>> So what does this prove? C++ is closer to C99?  C90 isn't C or C++?
> 
> It demonstrates what we already know - i.e. that C++ compilers can't 
> compile C programs. 

More topically it shows a C99 compiler can't compile a C90 program.

-- 
Ian Collins.
0
ian-news (10155)
4/8/2008 8:55:31 AM
Richard Heathfield wrote:
> Ian Collins said:
> 
>> Richard Heathfield wrote:
>>> Ian Collins said:
>>>
> <snip>
>>>> "/tmp/x.c", line 81: warning: implicit function declaration: toupper
>>>> "/tmp/x.c", line 86: warning: implicit function declaration: tolower
>>> Neither of these diagnostic messages is mandatory: implicit int is legal
>>> in C...
>>>
>> Read them again "implicit function declaration".  Your forgot <ctype.h>
> 
> No, I didn't. I just mis-typed "implicit function declaration". :-)  
> Implicit function declaration is, of course, legal in C90 (C).
> 
Now where did I leave my Tardis?

-- 
Ian Collins.
0
ian-news (10155)
4/8/2008 9:03:24 AM
Ian Collins said:

> Richard Heathfield wrote:
>> Ian Collins said:
>> 
<snip>
>> 
>>> "/tmp/x.c", line 81: warning: implicit function declaration: toupper
>>> "/tmp/x.c", line 86: warning: implicit function declaration: tolower
>> 
>> Neither of these diagnostic messages is mandatory: implicit int is legal
>> in C...
>> 
> Read them again "implicit function declaration".  Your forgot <ctype.h>

No, I didn't. I just mis-typed "implicit function declaration". :-)  
Implicit function declaration is, of course, legal in C90 (C).

> Implicit int is illegal in both C99 (C) and C++.

Right.

>>>> (Incidentally, this program also demonstrates that C99 isn't a
>>>> superset of C90.)
>> 
>> ....except, of course, when it isn't.
>> 
>>> So what does this prove? C++ is closer to C99?  C90 isn't C or C++?
>> 
>> It demonstrates what we already know - i.e. that C++ compilers can't
>> compile C programs.
> 
> More topically it shows a C99 compiler can't compile a C90 program.

Well, yes - but I think we knew that already. :-)  More generally, it 
illustrates the potentially interesting point that you can't necessarily 
tell what a program will do, just by looking at it.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
0
rjh (10791)
4/8/2008 9:03:42 AM
"Martin Ambuhl" <mambuhl@earthlink.net> wrote in message 
news:660lb5F2hf6c9U1@mid.individual.net...
> Don Bruder wrote:
>>
>> A C++ compiler *IS*, by definition, a C compiler. PLUS some stuff.
>
> The above is complete nonsense.  It is unbelievable that someone who knows 
> so little can write so much with a presumed air of authority. Until we see 
> evidence that Don Bruder has learned something, it is safer to ignore him. 
> For example.
>
Manners, manners, manners. Don Bruder is relatively new to the group and 
what he said is an easy mistake for a relatively well-informed person to 
make.

Most C programs won't compile under C++, but they will do so with a little 
bit of cosmetic messing about with casts. A design goal of C++ was to 
compile most C programs. C++ could have been made a strict superset of C but 
only by using abominations like underscores in keywords.

-- 
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

0
regniztar (3128)
4/8/2008 10:54:40 AM
[snips]

On Mon, 07 Apr 2008 22:41:49 -0700, Don Bruder wrote:

> A C++ compiler *IS*, by definition, a C compiler. 


#include <stdlib.h>

int main(void)
{
   char *s = malloc(100);
   if ( s ) free( s );
   return 0;
}

gcc -Wall -ansi -pedantic test.c compiles clean.  Note the use of the 
proper C idiom of *not* casting the return of malloc, which is both 
intentional and correct.


rename it to test.cpp, recompile with g++ and...

test.cpp: In function ‘int main()’:
test.cpp:5: error: invalid conversion from ‘void*’ to ‘char*’


Hmm.  A trivial 8 line program - if you count braces and white space - 
and it won't compile in C++.

Explain to us, then, how to get it to compile this perfectly valid C 
program.  No, not a modified version with casting in direct violation of 
proper C programming practise, show us how to get a C++ compiler to 
compile *that* program.  If, as you assert, a C++ compiler is a C 
compiler, the code should compile.  It doesn't.  It never will.  It 
cannot, as it is _C_ code, not _C++_ code and the two are not the same at 
all.

Don't like that one?  Try this:

#include <stdio.h>

int main(void)
{
  int new = 3;
  printf( "%d\n", new );
  return 0;
}

Again, compiles clean with gcc.  Save it as a C++ file and compile it 
with g++ and...

test.cpp: In function ‘int main()’:
test.cpp:5: error: expected unqualified-id before ‘new’
test.cpp:6: error: expected type-specifier before ‘)’ token
test.cpp:6: warning: format ‘%d’ expects type ‘int’, but argument 2 has 
type ‘int*’

Err what?  argument 2 has type int *?  No it doesn't, it has type int; 
says so right there: int new = 3;  No pointers at all.

You know, for a C compiler, g++ is pretty damn bad. Makes a fine C++ 
compiler, but it absolutely *blows* at compiling C code.  If, as you say, 
it is by definition also a C compiler, why does it suck so badly at 
compiling C code?

0
kbjarnason (4613)
4/8/2008 1:20:01 PM
    MMcL> "Martin Ambuhl" <mambuhl@earthlink.net> wrote in message
    MMcL> news:660lb5F2hf6c9U1@mid.individual.net...

    >> Don Bruder wrote:

    >> A C++ compiler *IS*, by definition, a C compiler. PLUS some
    >> stuff.

    > The above is complete nonsense.  It is unbelievable that someone
    > who knows so little can write so much with a presumed air of
    > authority. Until we see evidence that Don Bruder has learned
    > something, it is safer to ignore him. For example.

    MMcL> Manners, manners, manners. Don Bruder is relatively new to
    MMcL> the group and what he said is an easy mistake for a
    MMcL> relatively well-informed person to make.

Only if your definition of "relatively well-informed" is so vague as
to be useless; someone who thinks C++ is a proper superset of C,
modulo keywords, isn't very well-informed about either language.

And calling it complete nonsense isn't rude; neither is pointing out
that people who write complete nonsense to this group are frequently
corrected but otherwise ignored.

Charlton


-- 
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm


-- 
Charlton Wilbur
cwilbur@chromatico.net
0
cwilbur2 (421)
4/8/2008 1:28:57 PM
<OT>

In article <869518bc-bd77-477b-9493-29a2c454ad08@1g2000prf.googlegroups.com>,
2005  <FW3006@sbcglobal.net> wrote:
>On Apr 7, 9:56 pm, 2005 <FW3...@sbcglobal.net> wrote:

[Subject: Why would someone use c++ compiler on a C code?]

>> Would it suppress errors?
>>
>> Is he trying to hide errors in his code?
>
>He is using g++ on a *.c code!

g++ will act as a C compiler when given the file 'foo.c', unless you
specifically ask it to do otherwise.
Any of the gcc or g++ manuals, a GCC-specific newsgroup, or possibly a
Linux programming newsgroup should be able to give you the details.


>Also what is so different between gcc & cc compiler - any advantages?

gcc will always give you the GNU C compiler, unless the system was
deliberately set up to be confusing and/or broken.
cc will usually give you the system C compiler, which, where it isn't
GCC (on Linux systems and some others it is), can probably not
reasonably be expected to understand GCC-specific language extensions
and command-line arguments.


</OT>

dave

-- 
Dave Vandervies                                      dj3vande at eskimo dot com
But, Greg, this thread just kicked out /classes/ because they were too big and
clumsy and bloated, so how do you think we're likely to feel about *templates*?
                                            --Richard Heathfield in comp.lang.c
0
dj3vande3 (264)
4/8/2008 2:31:48 PM
"Kelsey Bjarnason" <kbjarnason@gmail.com> wrote in message 
news:sr7sc5-t31.ln1@spanky.localhost.net...
> [snips]
>
> On Mon, 07 Apr 2008 22:41:49 -0700, Don Bruder wrote:
>
>> A C++ compiler *IS*, by definition, a C compiler.
>
>
> #include <stdlib.h>
>
> int main(void)
> {
>   char *s = malloc(100);
>   if ( s ) free( s );
>   return 0;
> }
>
> gcc -Wall -ansi -pedantic test.c compiles clean.  Note the use of the
> proper C idiom of *not* casting the return of malloc, which is both
> intentional and correct.
>
>
Actually that idiom was retained, reluctantly, to avoid breaking reams of 
legacy code, as committee members have informed us in previous posts to this 
ng.

One effect is that if used in new code, the program will no longer compile 
under C++.

-- 
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

0
regniztar (3128)
4/8/2008 2:32:47 PM
dj3vande@csclub.uwaterloo.ca.invalid writes:

> <OT>
> In article <869518bc-bd77-477b-9493-29a2c454ad08@1g2000prf.googlegroups.com>,
> 2005  <FW3006@sbcglobal.net> wrote:
>>On Apr 7, 9:56 pm, 2005 <FW3...@sbcglobal.net> wrote:
>
> [Subject: Why would someone use c++ compiler on a C code?]
<snip>
>>He is using g++ on a *.c code!
>
> g++ will act as a C compiler when given the file 'foo.c', unless you
> specifically ask it to do otherwise.
<snip>
> gcc will always give you the GNU C compiler, unless the system was
> deliberately set up to be confusing and/or broken.

gcc will return the favour -- i.e. it will compile a C++ program if
the source is called, for example, x.cc.

I don't think you meant to imply otherwise, but some people might read
what you said as suggesting gcc is always a C compiler.  I find it
helps always to use -std=c89 or -std=c99 etc.  That way you get told
if you feed it a file that it takes to be in another language.

> </OT>

-- 
Ben.
0
ben.usenet (6790)
4/8/2008 4:25:09 PM
[snips]

On Tue, 08 Apr 2008 15:32:47 +0100, Malcolm McLean wrote:

>> gcc -Wall -ansi -pedantic test.c compiles clean.  Note the use of the
>> proper C idiom of *not* casting the return of malloc, which is both
>> intentional and correct.
>>
>>
> Actually that idiom was retained, reluctantly, to avoid breaking reams
> of legacy code, as committee members have informed us in previous posts
> to this ng.

The committee has precisely zero authority in terms of defining this as 
good practise or otherwise.  What defines it as good practise or bad is 
whether it works, and why.

Out there in the real world, there exist compilers which do *not* warn 
you about failure to include appropriate headers, but which will - are 
required to - warn about invalid assignments, such as from int to pointer.

If and when one's code can be reasonably certain of never, ever 
encountering such a compiler in the code's entire lifetime, then and only 
then will this cease to be a useful idiom.

Maybe this will come when C90 compilers are dead and buried, but given 
the sickly snail's pace with which C99 has been adopted, I wouldn't count 
on it happening tomorrow.

0
kbjarnason (4613)
4/8/2008 5:08:02 PM
Malcolm McLean wrote, On 08/04/08 15:32:
> 
> "Kelsey Bjarnason" <kbjarnason@gmail.com> wrote in message 
> news:sr7sc5-t31.ln1@spanky.localhost.net...
>> [snips]
>>
>> On Mon, 07 Apr 2008 22:41:49 -0700, Don Bruder wrote:
>>
>>> A C++ compiler *IS*, by definition, a C compiler.
>>
>>
>> #include <stdlib.h>
>>
>> int main(void)
>> {
>>   char *s = malloc(100);
>>   if ( s ) free( s );
>>   return 0;
>> }
>>
>> gcc -Wall -ansi -pedantic test.c compiles clean.  Note the use of the
>> proper C idiom of *not* casting the return of malloc, which is both
>> intentional and correct.
>>
> Actually that idiom was retained, reluctantly, to avoid breaking reams 
> of legacy code, as committee members have informed us in previous posts 
> to this ng.

I can't remember any such post. In fact, void* was *invented* by the 
standards committee specifically to get rid of the need for casts in a 
number of places http://www.lysator.liu.se/c/rat/c2.html#3-2-2-3
Note this quote from there...
| ... Adoption of this type was stimulated by the desire to specify
| function prototype arguments that either quietly convert arbitrary
| pointers...

> One effect is that if used in new code, the program will no longer 
> compile under C++.

Well, seeing as new C code is C code rather than C++ this is not a problem.
-- 
Flash Gordon
0
spam331 (4048)
4/8/2008 6:37:43 PM
In article <660lb5F2hf6c9U1@mid.individual.net>,
Martin Ambuhl  <mambuhl@earthlink.net> wrote:
>Don Bruder wrote:
>> In article 
>> <a46ea80c-3394-443b-bade-2f38f18273da@q27g2000prf.googlegroups.com>,
>>  2005 <FW3006@sbcglobal.net> wrote:
>> 
>>> Would it suppress errors?
>>>
>>> Is he trying to hide errors in his code?
>> 
>> A C++ compiler *IS*, by definition, a C compiler. PLUS some stuff. 
>
>The above is complete nonsense.  It is unbelievable that someone who 
>knows so little can write so much with a presumed air of authority. 
>Until we see evidence that Don Bruder has learned something, it is safer 
>to ignore him.  For example.

It really pisses the regs off when intelligent people come on here and
express views not in accord with the party line.  They are soon branded
"trolls" and most (but not all) leave soon after.

>> In general, unless you're trying to compile C++ code (in which case, a 
>> "plain C" compiler just can't cope) it really doesn't much matter if you 
>> use a "plain" C compiler, or a C++ compiler on a straight C source.
>
>this is obvious bullshit.

Yup, Marty.  Always the charmer, eh?

0
gazelle2 (1307)
4/8/2008 7:44:46 PM
Reply: