Thiago spaketh: > I'd like to propose we add Q_DECL_NOEXCEPT to many methods in our API. > > We already took the decision to turn exception off in most modules, except > QtCore and where exceptions were used, like QtXmlPatterns. This is the next > step. > > The Q_DECL_NOEXCEPT macro expands to noexcept, which is a new C++11 > keyword. > It is equivalent to noexcept(true), also new in C++11, and it means the > method > declares that it does not throw any exceptions. > > The benefits are: > - callers do not need to emit exception handlers around such functions > - the compiler may assume that no exception unexpectedly happens inside > that > function body, foregoing exception handlers inside it as well. > > The first behaviour is present with a C++03's empty exception specification > (i.e., throw() in the function declaration), but the second behaviour is > new > in C++11. In the previous standard, the compiler was forced to emit > exception > code for the case when exceptions did happen even when they shouldn't. For > that reason, the C++03 exception specification is deprecated. > > The drawback is that it makes the code ugly. > > The macro expands to nothing in C++98 mode. That means code using the API > so > marked and compiling in C++98 mode will simply not gain the benefits of the > keyword, but should see no side effects. > > The presence of the keyword does not affect binary compatibility. With the > Itanium C++ ABI, it's not present in the mangling. MSVC2010 does not > supoprt > it yet, so I cannot verify what it does. However, since C++11 support > cannot > be turned on or off on it, the keyword will be enabled or it won't > depending on > the compiler version, which means that binary compatibility is irrelevant. > But > if it does encode it in the mangling, we will not be able to add the > keyword > to methods in 5.1 or later. >
Totally agree, support Q_DECL_NOEXCEPT being added to many methods in the API. I've seen many developers confuse "exception-handling" with normal-error-handling, and think it would be best to establish clarity for those operations that do not throw (and which logically should never throw). This is consistent with the C++11 intent of "increased type safety", and we should use it, IMHO. The benefits seem compelling: (a) It better documents the design/implementation details (b) It may lead to more efficient compiled-binary I concede Thiago's identified drawback: (c) It makes the code ugly ...however, it adds-the-caveat that the code "ugliness" is the same as saying it better documents the design/implementation detail. Since this is a cross-platform reusable library and users rely upon the Qt docs anyway, I don't think that's much of a penalty (if any). > The question that remains is: what methods shall we add this to? We can > add it > to any method for which we can *prove* that it will never throw, which are: > - leaf functions > - functions calling only C functions or other noexcept functions > > Outside of QtCore, I propose we add it only to methods that are called > often > and frequently. In QtCore, I propose we add it to most tool methods that > are > provably noexcept. For example, the qHash functions, QMutex, our memory > allocation routines (the throwing is in inline code), etc. > > PS: to be clear: new throws. I'd vote to "add-it-everywhere-possible", starting with those Thiago identified. IMHO it should be "good practice" for developers to add-this-to-their-API-review-checklist to use the "Q_DECL_NOEXCEPT" everywhere possible as they grow/maintain their APIs. --charley
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development