gcc : c++11 : full support : eta?

[Alec Teal]

On 24/01/13 19:55, Diego Novillo wrote:
> ...
> Agreed.
>
> I do see, however, a few areas where Clang/LLVM have gone that I do
> not think GCC is currently thinking of entering: "toolability" (for
> the lack of a better term).  Clang's design follows a different path
> than g++.  It's not just a code generating parser, it is a pure parser
> that also generates code.  The difference makes it suitable for any
> kind of tool that needs to understand C++: static analyzers, code
> re-formatters, syntax highlighters, and other similar tools.
> Additionally, it is designed as a library, so it can be embedded into
> applications.
I don't know enough yet but GCC seems to be partitioned, this back and 
front end, there's some point where there's no GIMPLE and then there is, 
whenever I've got a big code-blob and need to do something with it where 
I cannot copy and paste the bits I want to keep, you know, you can't 
just  take the good parts, I've turned to Biology:

When DNA replication happens (or protein synthesis - please biologists 
don't be bionazis) the DNA is not 'unzipped' for very long and doesn't 
leave the safety of the membrane around the nuclease (this time last 
year, I would have known the name!) so instead it is transcribed.

An enzyme latches onto the 3`UTR end and moves to the 5`UTR end, 
unzipping the DNA and rezipping it in it's wake, and it transcribes the 
DNA bases to the complimentary base in RNA, rather than the compliment 
to DNA's Adenine (thymine) RNA has Uracil. Fun fact.

Anyway this fragile DNA structure that can't leave the nuclease or be 
split up (GCC) can be traversed by this enzyme and spit off useful 
strands of RNA that expresses the data of the DNA.

No fact checking - hope it wasn't to bad, and worthy of writing, with 
GCC why not add the ability to "siphon" off useful structures and output 
a form that can be independent of the DNA that is GCC (serialised form)

The thing that'd do this would be inside GCC so would have access to all 
context and whatever data is available. I think that was a superb metaphor.
> That is a need that g++ cannot currently satisfy.  With plugins, one
> could do something along those lines, but they are heavier, and are at
> the mercy of the full compiler.  Additionally, g++ has very low
> fidelity wrt the input program; it breaks down the original C++ input
> almost immediately.
I don't quite follow, as opposed to? (Sorry if dumb question)
> That is not necessarily a bad thing for g++.  But, to effectively
> compete in those areas, it will need to be significantly re-organized.
>
> LLVM has similar properties, at least as far as the middle end of the
> compiler is concerned.  GCC still has an edge wrt backend portability.
>
>
> Diego.
>
Alec