I'd say go ahead. Since adding it shouldn't change the ABI/name mangling, we can introduce this gradually anyway.
Cheers, Lars On Aug 2, 2012, at 2:50 PM, ext Thiago Macieira <thi...@kde.org> wrote: > 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. > > > 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. > > -- > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org > Software Architect - Intel Open Source Technology Center > PGP/GPG: 0x6EF45358; fingerprint: > E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development