what's the differnece between gcc and g++?

[y***@gmail.com]

Hello, everyone,

The difference between gcc and g++ puzzles me. Here "gcc" referes to
the
"gcc" command , not the GNU Compiler Collection.

According to my study, "gcc" invoks cc1plus under /usr/libexec/gcc/ ,
and "g++" invokes cc1plus under /usr/libexec/gcc/. As C is a subset of
C++, why we cannot use g++ alone to compile all C/C++ programs.
Why we still need a "gcc" sitting aside?

Can anyone explain briefly to me? Thanks!

-Andy

[Paul Pluzhnikov]

***@gmail.com writes:

> According to my study, "gcc" invoks cc1plus under /usr/libexec/gcc/ ,
> and "g++" invokes cc1plus under /usr/libexec/gcc/.

'gcc' will invoke different compiler depending on the file extension,
and other command line arguments.

For example:

echo "int main() { return 0; }" > junk.c && ln junk.c junk.cpp
gcc -c junk.c # invokes 'cc1'
gcc -c junk.cpp # invokes 'cc1plus'
gcc -c -xc junk.cpp # 'cc1'
gcc -c -xc++ junk.c # 'cc1plus'

The exact location where 'cc1' etc. come from also depends on how
gcc was configured, and command line flags, such as -B.

Finally, at link time 'g++' links libstdc++, and 'gcc' doesn't.

> As C is a subset of C++,

C is not a proper subset of C++: many programs that are valid C
are not valid C++, and vice versa.

Here is a trivial example:

$ echo "int main() { free(malloc(1)); return 0; }" > junk.c
$ gcc -c junk.c && echo ok
ok

$ g++ -c junk.c && echo ok
junk.c: In function `int main()':
junk.c:1: error: `malloc' undeclared (first use this function)
junk.c:1: error: (Each undeclared identifier is reported only once for each
function it appears in.)
junk.c:1: error: `free' undeclared (first use this function)

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

[Rolf Magnus]

***@gmail.com wrote:

> Hello, everyone,
>
> The difference between gcc and g++ puzzles me. Here "gcc" referes to
> the
> "gcc" command , not the GNU Compiler Collection.
>
> According to my study, "gcc" invoks cc1plus under /usr/libexec/gcc/ ,
> and "g++" invokes cc1plus under /usr/libexec/gcc/.

> As C is a subset of C++,

You're wrong here. It is not.

> why we cannot use g++ alone to compile all C/C++ programs.

Because there is no such thing as "C/C++". For the compiler, it's pretty
much irrelevant, as long as it has some way of knowing which language you
compile. gcc will try to gather that information from the file name, while
g++ will always try to compile the code as C++. Another way is to
explicitly specify the language to be compiled.
But linking is another story. When linking the result generated from C++
code, you need different linker options than for C code, and the linker
can't find out the language that the object code was compiled from, so you
have to tell it explicitly. When you use gcc for linking, it will pass the
options relevant for C code to the linker (unless you explicitly specify
the language), while g++ will link it as C++ code.

[Maxim Yegorushkin]

Rolf Magnus wrote:

[]

> But linking is another story. When linking the result generated from C++
> code, you need different linker options than for C code, and the linker
> can't find out the language that the object code was compiled from, so you
> have to tell it explicitly. When you use gcc for linking, it will pass the
> options relevant for C code to the linker (unless you explicitly specify
> the language), while g++ will link it as C++ code.

Does the linker care about the language object files were generated
from? From what I gather from info ld the only c++-specific option
which may affect the (binary) output of ld is -Ur. Am I missing
something?

[Robert Heller]

At 4 Sep 2006 00:19:35 -0700 "Maxim Yegorushkin" <***@gmail.com> wrote:

>
> Rolf Magnus wrote:
>
> []
>
> > But linking is another story. When linking the result generated from C++
> > code, you need different linker options than for C code, and the linker
> > can't find out the language that the object code was compiled from, so you
> > have to tell it explicitly. When you use gcc for linking, it will pass the
> > options relevant for C code to the linker (unless you explicitly specify
> > the language), while g++ will link it as C++ code.
>
> Does the linker care about the language object files were generated
> from? From what I gather from info ld the only c++-specific option
> which may affect the (binary) output of ld is -Ur. Am I missing
> something?

g++ adds -lstdc++ (at least) to the link -- that is, c++ has additional
run time libs over plain C.

>
>

--
Robert Heller -- 978-544-6933
Deepwoods Software -- Linux Installation and Administration
http://www.deepsoft.com/ -- Web Hosting, with CGI and Database
***@deepsoft.com -- Contract Programming: C/C++, Tcl/Tk

[Rolf Magnus]

Maxim Yegorushkin wrote:

> Rolf Magnus wrote:
>
> []
>
>> But linking is another story. When linking the result generated from C++
>> code, you need different linker options than for C code, and the linker
>> can't find out the language that the object code was compiled from, so
>> you have to tell it explicitly. When you use gcc for linking, it will
>> pass the options relevant for C code to the linker (unless you explicitly
>> specify the language), while g++ will link it as C++ code.
>
> Does the linker care about the language object files were generated
> from?

No.

> From what I gather from info ld the only c++-specific option
> which may affect the (binary) output of ld is -Ur. Am I missing
> something?

-lstdc++, and possibly some target-specific options.