https://bugs.kde.org/show_bug.cgi?id=400632
Christoph Cullmann <cullm...@kde.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |cullm...@kde.org
--- Comment #3 from Christoph Cullmann <cullm...@kde.org> ---
Hi,
exception safety is of no concern for us.
If any of the standard functions throws (like e.g. new), we can't recover
anyways and the standard handler will abort (or we will crash). The same holds
for any out-of-bounds/... errors,
they shall terminate. We don't use exceptions for recoverable error handling.
If you take a look at what Qt promises, it is more or less the same on the
level beyond pure containers.
http://doc.qt.io/qt-5/exceptionsafety.html
On the other side, I have no issues with improving the use of raw pointers.
I can agree that the guidelines to avoid them and wrap them in zero-cost
unique_ptr's for example if feasible sounds ok.
For example
m_macros = new Macros();
m_mappings = new Mappings();
m_registers = new Registers();
m_searchHistory = new History();
m_replaceHistory = new History();
in GlobalState looks like such a case. On the other side, I am not sure why
this things are not just in-place members, which would avoid the
heap-allocation. (perhaps to hide them from the header, but given this is a
purely internal class, I would not mind that being changed).
If you have time to do such cleanups, which lead to less potential memory
handling errors, any patch on http://phabricator.kde.org is welcome.
--
You are receiving this mail because:
You are watching all bug changes.
