On quinta-feira, 2 de agosto de 2012 14.50.04, Thiago Macieira wrote:
> 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.

Updates on the noexcept work:

1) the macro we'll use is now Q_DECL_NOTHROW, which is documented to be one
of:
 - C++11 noexcept
 - MSVC throw()
 - empty

MSVC has deviated from the C++98 standard for years about what throw() means.
In their definition, the caller is guaranteed that the callee will not throw
and the callee simply expects that no exceptions will leak. If they do,
undefined behaviour ensues, most likely a crash. But there's no overhead for
either party.

2) nothrow functions need to be aware if any functions they call do throw. Any
code interfacing with a C++ function not marked nothrow can potentially throw,
so investigate the dependencies first. In addition, C functions defined by POSIX
as cancellation points[1] should also be considered as throwing. In the IA-64
C++ ABI defines that a thread cancellation will unwind the stack like an
exception, with no possibility of catching.

3) MSVC reportedly stores the exception specification in the mangled name. I
have not been able to reproduce this with my MSVC 2010 and I haven't been able
to reach Marius for confirmation yet. It could be either MSVC 2012 or some
special compiler flags. More on this later.

[1]
http://pubs.opengroup.org/onlinepubs/007908799/xsh/threads.html#tag_000_010_008_002

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to