Throwing std::ios_base::failure on formatted input with gcc 6.2

Edward Diener eldlistmailingz@tropicsoft.com
Thu Oct 27 17:26:00 GMT 2016


On 10/27/2016 10:35 AM, Jonathan Wakely wrote:
> On 27 October 2016 at 15:34, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>> On 27 October 2016 at 15:30, Edward Diener
>> <eldlistmailingz@tropicsoft.com> 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.

I understand it. Thanks for the clarifications.



More information about the Gcc-help mailing list