On Tue, Jun 24, 2014 at 11:12:38AM -0600, Tom Tromey wrote: > Trevor> hrm, I know basically nothing about the upcoming changes, but I would > Trevor> have expected linking c++03 code against c++11 code would be fine > Trevor> especially when the interface doesn't involve any stl. > > https://gcc.gnu.org/wiki/Cxx11AbiCompatibility > > This warns against mixing with C++98, which seems to be how GCC is > built. > > While I agree that in this specific case it is probably safe, since gcc > in general isn't a heavy user of libstdc++, I think it's reasonable to > simply follow gcc. This is safer in case gcc changes; and the benefit
yeah, I'm not disagreeing at this point. > from C++11 in libcc1 is modest, especially when you consider the extra > template magic we'd need in order to actually use variadic templates for > the RPC stuff. It would get a little more than that, actually deleting the copy ctors and stuff you don't want people to call is one thing that comes to mind. > > Trevor> Well, we build everything or at least everything I've seen with > Trevor> -fno-exceptions, so if something does throw we'll just crash right? > Trevor> istm we certainly write code calling the throwing new with that > Trevor> expectation. > > Gcc's coding conventions say that code ought to be exception-safe in > case exceptions are used in the future. Search for "Exceptions" here: > > https://gcc.gnu.org/wiki/CppConventions I think that's a good idea in general, mostly because it results in simpler code, I think the idea gcc will be exception safe in a reasonable amount of time is a bit of a pipe dream. > > I think retaining the std::nothrow is safer in view of this, and doesn't > cause any problems. I think in general trying to handle allocator failure is a waste of time, that is all the places we call the throwing new today we'd want to keep doing that in a world with exceptions and just let the exception kill us. So assuming you actually want to handle allocator failure in this particular case for some reason that seems reasonable. Trev > > Tom