This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]