Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #13971

Re: OS X compiler

Show all headers | View raw

Juha Nieminen <nospam@thanks.invalid> writes:
> The main reason why Apple uses clang instead of gcc (a gcc newer
> than 4.2 that is) is because of licensing issues. Apple is stuck
> with gcc 4.2 because it's the last one to use the (L)GPL 2 license,
> while all the newer ones use (L)GPL 3, which is incompatible for
> iPhone development. And gcc 4.2 is getting antiquated by the month.

Yeah I know.

>  (Also, it's true: In many cases clang produces significantly better
> error messages and warnings than gcc does.)

I know that one of clang's big "bullet points" is good error messages,
but my experience (I use [modern versions of] both compilers) the
difference isn't particularly great in practice.  There are certain
very specific scenarios where clang definitely does produce nicer
messages (e.g. it tracks macro expansions better so it can reference
the offending macro when an error comes from one), but I've found them
to be relatively rare.  [remember, gcc diagnostics keep getting better
too!]

> Perhaps the major (which in many cases isn't so "major") problem
> with clang is that it's not as good at optimizing as gcc is. Even
> gcc 4.2 produces faster code than clang, not to talk about the
> latest gcc (which has several significant improvements on that
> department).

Clang trunk is catching up though ... I used to avoid clang for
anything but testing, because clang-generated code that ran at
literally half the speed of gcc-generated code (on some speed critical
code I care about) -- but recently the clang trunk is showing much
better results.

I think both are very usable compilers these days, if you use the
recentish versions.  Gcc optimizes somewhat better, and has better
support for C++11, but clang is a bit faster in compilation (~10-15%
IME), and sometimes does offer better diagnostics.  [I find it useful
to compile with both, because using multiple independent compiler
implementations helps to identify portability problems in my own code,
which might slip through the cracks in a single compiler.]

[Another issue is the standard C++ library.  Clang's own library,
libc++ doesn't really seem ready for prime time (e.g. the installation
instructions basically say "don't try this if you aren't running
OSX"), and while clang can use libstdc++ (gcc's library), it's not
entirely trivial to find a version which is both recent enough to
support new C++11 features and which clang can handle... (primarily
due to the use of C++11 features in the library implementation of
C++11 classes).]

-Miles

-- 
Politeness, n. The most acceptable hypocrisy.

Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

OS X compiler Ebenezer <woodbrian77@gmail.com> - 2012-02-12 13:32 -0800
  Re: OS X compiler Miles Bader <miles@gnu.org> - 2012-02-13 10:26 +0900
    Re: OS X compiler Ebenezer <woodbrian77@gmail.com> - 2012-02-12 19:12 -0800
    Re: OS X compiler Juha Nieminen <nospam@thanks.invalid> - 2012-02-13 10:17 +0000
      Re: OS X compiler Miles Bader <miles@gnu.org> - 2012-02-13 20:15 +0900
        Re: OS X compiler Ebenezer <woodbrian77@gmail.com> - 2012-02-13 20:08 -0800

csiph-web