Request for clarification regarding C++ version requirements in non-C++ frontends

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Request for clarification regarding C++ version requirements in non-C++ frontends

The Other
Hi,

I'm currently working on a branch of gccrs aiming to create some kind of
Rust frontend within GCC. I've advanced to the stage where attempting to
use pre-C++11 features is becoming inconvenient, particularly in the
unique_ptr department. Part of the frontend AST is best expressed as
vectors of pointers (due to polymorphism), and the gnu::unique_ptr clone of
std::unique_ptr states it does not support standard containers like vector.

I am aware that GCC currently has the policy of being compilable with a
C++03 compiler, but I was wondering whether frontends other than the C and
C++ ones are also subject to this restriction. For example, would it be
acceptable if the frontend was written in C++11, given that it can still be
compiled by g++?

I see two other possible solutions if this restriction does in fact apply:

If gnu::unique_ptr does in fact work with vector, I could simply use that.
However, the lack of move semantics would lead to a very clunky kind of
interface for the AST, which I would rather avoid, if possible.

I could also use regular pointers, but this would make memory management
more "clunky", so I would also prefer not to do so if possible. Perhaps
just as importantly, the lack of move semantics would have performance
implications - the deep copying of the vectors required to simplify memory
management would be quite inefficient.

Thanks,
Theo
Reply | Threaded
Open this post in threaded view
|

Re: Request for clarification regarding C++ version requirements in non-C++ frontends

Richard Biener-2
On October 19, 2019 9:11:52 AM GMT+02:00, The Other <[hidden email]> wrote:

>Hi,
>
>I'm currently working on a branch of gccrs aiming to create some kind
>of
>Rust frontend within GCC. I've advanced to the stage where attempting
>to
>use pre-C++11 features is becoming inconvenient, particularly in the
>unique_ptr department. Part of the frontend AST is best expressed as
>vectors of pointers (due to polymorphism), and the gnu::unique_ptr
>clone of
>std::unique_ptr states it does not support standard containers like
>vector.
>
>I am aware that GCC currently has the policy of being compilable with a
>C++03 compiler, but I was wondering whether frontends other than the C
>and
>C++ ones are also subject to this restriction. For example, would it be
>acceptable if the frontend was written in C++11, given that it can
>still be
>compiled by g++?

I think it is acceptable to write drontends not required for bootstrapping in any language GCC supports itself.

Richard.

>I see two other possible solutions if this restriction does in fact
>apply:
>
>If gnu::unique_ptr does in fact work with vector, I could simply use
>that.
>However, the lack of move semantics would lead to a very clunky kind of
>interface for the AST, which I would rather avoid, if possible.
>
>I could also use regular pointers, but this would make memory
>management
>more "clunky", so I would also prefer not to do so if possible. Perhaps
>just as importantly, the lack of move semantics would have performance
>implications - the deep copying of the vectors required to simplify
>memory
>management would be quite inefficient.
>
>Thanks,
>Theo