[Development] Proposal: adding Q_DECL_NOEXCEPT to many methods

[lars.knoll at nokia.com]

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 <thiago at 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 at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development