gcc : c++11 : full support : eta?
Gabriel Dos Reis
gdr@integrable-solutions.net
Fri Jan 25 18:16:00 GMT 2013
On Thu, Jan 24, 2013 at 1:59 PM, Jeff Law <law@redhat.com> wrote:
> On 01/24/2013 12:55 PM, Diego Novillo wrote:
>>
>>
>> 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.
>
> Yup. We kicked stuff in this area around as well as we were discussing the
> problems early folding presents. In an ideal world, the G++ parser would
> turn into something that can be used not just for G++, but as a library for
> other tools that need to parse C++ code (doxygen, gdb and I'm sure there's
> others).
First all of I should confess that I have had long
interest in having a "modular" g++ parser in the
sense that I would like the ability to retarget it to
other purposes that we cannot realistically expect
a single simple C++ compiler to satisfy simultaneously.
However parsing C++ is a very tricky. Depending
on the level of fidelity to the C++ spec, parsing involves
template instantiation, which itself may involve overload
resolution, etc. So when we are talking about a C++ parser
module, this means we need a much better typed AST to represent
the semantics graph before gimplification.
-- Gaby
More information about the Gcc
mailing list