[Interest] MSVC 2013 Bug?

Igor Mironchik igor.mironchik at gmail.com
Thu Nov 12 23:22:35 CET 2015



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 *

gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2)

-- 
Best Regards,
Igor Mironchik.




More information about the Interest mailing list