Heads up, g++ in Xcode 5 points to Clang

[Iain Buclaw]

On 28 October 2013 20:22, Joakim <joakim at airpost.net> wrote:
> On Monday, 28 October 2013 at 19:02:35 UTC, Iain Buclaw wrote:
>>
>> On 28 October 2013 18:38, Joseph Rushton Wakeling
>> <joseph.wakeling at webdrake.net> wrote:
>>>
>>> It certainly seems to be true that LLVM is moving faster innovation-wise.
>>> I
>>> don't know how much of that is down to any architectural advantages, how
>>> much might be because they support less targets and so have a lower
>>> maintenance burden, and how much of it is just the scale of resources
>>> being
>>> put into it.
>>>
>>
>> I don't see it that way.  Up until now at least I haven't seen
>> anything they do that wasn't already do-able in GCC.  They just do a
>> better job at PR (which is what you expect from Apple anyway).
>
> Really?  The claims that llvm has a cleaner codebase, is easier to use
> because it's all properly split up into different libraries, and introduces
> new features like better error reporting: that's all "PR?"

GCC approach to libraries has not been to load them dynamically, take
libiberty for example:
http://gcc.gnu.org/onlinedocs/libiberty/Using.html#Using  - and the
"better" error reporting was in gcc, just off by default (Clang added
a little more with addition of ~~ tildas ~~).

>From what I've read and gathered from David over a period of some
conversations.  Clang infrastructure-wise is much like gcc-3.3/gcc-4.0
was - they have a well defined AST that is capable of representing
everything you'd expect in a typical C-family language, with a
backdoor to lower level register/assembly representations for
target-specific implementations. The direction that GCC went in later
versions was closing the backdoor and moving backend-specific code in
various frontends to the middle end.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';