On quinta-feira, 2 de agosto de 2012 13.00.22, lars.kn...@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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
