This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Request for clarification regarding C++ version requirements in non-C++ frontends
- From: The Other <simplytheother at gmail dot com>
- To: gcc at gcc dot gnu dot org
- Date: Sat, 19 Oct 2019 15:11:52 +0800
- Subject: Request for clarification regarding C++ version requirements in non-C++ frontends
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