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.
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
