On 27 October 2016 at 15:34, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote: > On 27 October 2016 at 15:30, Edward Diener > <eldlistmailingz@xxxxxxxxxxxxxx> wrote: >> On 10/27/2016 10:00 AM, Jonathan Wakely wrote: >>> >>> On 27 October 2016 at 14:52, Edward Diener wrote: >>>> >>>> It sounds like you are also saying that there is no way to catch the old >>>> type, even if I wanted to, since the header file declaration has the >>>> decorated attribute. >>> >>> >>> No, the attribute is only present conditionally, see >>> https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html >>> >>> If you compile with _GLIBCXX_USE_CXX11_ABI defined to zero then you >>> get the declaration of the old type (and the old COW std::string, and >>> the old std::list with O(n) size()). >>> >> >> Thanks ! IMO clearly you should be throwing the std::ios_base::failure which >> corresponds to the _GLIBCXX_USE_CXX11_ABI macro setting being used. > > The exception is thrown from code inside libstdc++.so, which is > already compiled and can't be affected by a macro defined when you > #include <iostream>. > > We could maybe set a thread-local variable every time an iostream > operation is performed, based on the macro value, and have the library > inspect the thread-local to decide which type to throw, but that would > be ugly, and still not always do the right thing. > > >> That gcc >> is throwing the the old type even when _GLIBCXX_USE_CXX11_ABI is defined as >> 1 cannot be right. But I think that is what you already said. > > No, I said I'm going to change it to always throw the new type. It > will won't depend on the macro. Sorry, that was meant to say it *still* won't depend on the macro.
