[Interest] MSVC 2013 Bug?

Elvis Stansvik elvstone at gmail.com
Fri Nov 13 00:11:43 CET 2015


2015-11-12 23:57 GMT+01:00 Elvis Stansvik <elvstone at gmail.com>:
> 2015-11-12 23:22 GMT+01:00 Igor Mironchik <igor.mironchik at gmail.com>:
>>
>>
>> On 13.11.2015 00:44, Thiago Macieira wrote:
>>>
>>> On Thursday 12 November 2015 23:56:20 Igor Mironchik wrote:
>>>>>
>>>>> First of all, allocating memory when throwing exceptions is bad
>>>>> practice.
>>>>> Avoid it by redesigning your code.
>>>>
>>>> Can you, please, explain why allocating memory when throwing exception
>>>> is bad practice? Or just can you give a link on any article about this
>>>> question.... Thank you.
>>>
>>> Because allocating memory in response to an OOM situation is stupid, so
>>> std::exception doesn't require it; instead, it uses a pointer that is
>>> expected
>>> to be valid forever. The exception mechanism uses a pre-allocated buffer
>>> so
>>> that exceptions can still work in an OOM condition.
>>>
>>>>> Because toLocal8Bit() returns a QByteArray and QByteArray has an
>>>>> operator
>>>>> const char*(). Why would it not be possible?
>>>>>
>>>>> Do note that it compiles, but it's probably incorrect because
>>>>> std::runtime_error will probably be carrying a dangling pointer.
>>>>>
>>>>> Like I said, you should redesign so you don't allocate memory when
>>>>> throwing
>>>>> exceptions.
>>>>
>>>> Thank you, I understood. Just interesting why Qt 5.5.1 on Windows
>>>> compiled without QT_NO_CAST_FROM_BYTEARRAY and on Linux with this one?
>>>
>>> It isn't. Your test is faulty. The only piece of code that turns that
>>> macro on
>>> is moc's own build.
>>
>>
>> I found the problem. The problem on Linux with gcc. In std::runtime_error I
>> have:
>>
>>   class runtime_error : public exception
>>   {
>>     __cow_string _M_msg;
>>
>>   public:
>>     /** Takes a character string describing the error.  */
>>     explicit
>>     runtime_error(const string& __arg);
>>
>> #if __cplusplus >= 201103L
>>     explicit
>>     runtime_error(const char*);
>> #endif
>>
>> It looks like a bug. c_tor with string should be in __cplusplus macro, but
>> not c_tor with const char *
>
> That does look strange indeed. And it seems it's the wrong way around
> for several of the other exceptions as well (if I look at my stdexcept
> here, gcc 5.2.0).

Actually it's not wrong. It's the const char* version that was added in C++11.

http://en.cppreference.com/w/cpp/error/runtime_error is wrong (I'm
guessing that's where you looked as well).

Elvis

>
> Elvis
>
>>
>> gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2)
>>
>> --
>> Best Regards,
>> Igor Mironchik.
>>
>> _______________________________________________
>> Interest mailing list
>> Interest at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest



More information about the Interest mailing list