On 06/20/14 09:33, Tom Tromey wrote:
"Trevor" == Trevor Saunders <tsaund...@mozilla.com> writes:
Trevor> I'm curious, what is the reason you choose not to write this in C++11 or
Trevor> later? Its distributed with gcc, so the only case where you aren't
Trevor> building with the in tree compiler and libraries is when your cross
Trevor> compiling gcc, and it doesn't seem particularly important to support
Trevor> building the plugin or library in that configuration. So istm you could
Trevor> go all the way and assume you are being built with trunk gcc and
Trevor> libraries.
The plugin has to be ABI compatible with GCC itself, and my
understanding was that C++11 and "however GCC is built" are not
necessarily compatible.
Presumably you're referring to the upcoming abi breakage for C++ pair &
list.
There's ways around that with the ABI tagging we're using, but at least
for now, the safe thing to do for something that must be ABI compatibile
with GCC itself is to stick with C++03 mode.
Switching to C++11 would be an improvement -- variadic templates would
simplify the RPC code (with a complicated caveat). So if it is possible
I am interested.
There'll probably be a day when we can bless C++11 for building GCC
itself and any associated plugins, but we're not at that point right now.
Trevor> So can we add C++ stuff to libiberty and allow building
Trevor> libiberty without it for binutils / gdb, or can we do something
Trevor> else to avoid this kind of stuff?
One way would be to just make a new top-level directory for a new
library.
Seems like the easiest solution, at least for now.
Thanks. I changed it to do a NULL check. It's nothrow because nothing
in libcc1 or gdb is prepared for a C++ exception. While I like
exceptions (gdb uses its own longjmp-based exception system
extensively), my understanding is that they aren't currently used in
gcc.
Right. Or if we're using them in GCC, any such use is well buried in
non-critical , not widely known & marginally, if at all, tested code.
Jeff