[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