[Development] Proposal: adding Q_DECL_NOEXCEPT to many methods

[Thiago Macieira]

On quinta-feira, 2 de agosto de 2012 13.00.22, lars.knoll at nokia.com wrote:
> I'd say go ahead. Since adding it shouldn't change the ABI/name mangling, we
> can introduce this gradually anyway.

By the way, let's be conservative instead of doing it throughout.

Once added, the noexcept keyword cannot be removed. That breaks behaviour 
compatibility, even if binary compatibility is retained. That is, noexcept 
becomes part of our API.

That means adding noexcept to a method means we tie our hands in that method 
to never throw -- most often, never fail. If the method can never fail, it's 
usually a good candidate.

For example, in when I was just now adding it to qHash for QDateTime, I 
realised it does complex operations. Right now, none of those operations 
allocate memory, but it's actually very close to doing that. QDateTime has a d 
pointer and the hash function does some manipulation of the data. If I add it 
now, it means it cannot allocate memory, ever, in Qt 5. For that reason, I'm 
not sure I can do it: what if the implementation for QDateTime when timezones 
are taken into account needs to new?

The same applies to QMutex::lock: I'm not sure if I should add it. I want to. 
But what if we write a std::mutex implementation next year? That one can 
throw. I'm going to add, though, on the assumption that we'd translate 
std::mutex's exceptions to error codes.

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120802/8f5681a9/attachment.sig>