Travis Vitek wrote:
Martin Sebor wrote:
Farid Zaripov wrote:
I've just tried to declare and define __rw_once with throw(...)
exception specification and compiler doesn't issues warning in
that case.
Yes, but the documentation linked to explicitly says...
Explicit exception specifications are not allowed on C functions.
[http://msdn2.microsoft.com/en-us/library/wfa0edys(VS.80).aspx]
Yet they describe the behavior of functions, including those
with C linkage, in terms of explicit exception specification.
How ironic!
I tested, it does compile, and the destructors are getting called as
they should when an explicit throw(...) spec is added to the C linkage
function. That said, I cringe at the thought relying on behavior that is
documented to not work or is not supported.
No kidding!
Maybe when the documentation is referring to C functions it means
functions that are compiled as C source [x.c instead of x.cpp] and not
functions with C linkage?
Who knows... Have you tried it?
Good to know! We still need to decide how to handle this in
the general case (for compilers that behave like MSVC, if
there are any) but we can certainly start using this extension
to silence the MSVC warnings.
Is the goal really to just squelch the warnings? I hope not.
No, not just that (we could simply use #pragma warning to silence
them if that was the only goal).
So back at square one, I have another question. Lets assume a program
will abort() if an exception is thrown through a C function. This
characterization test will fail, and the build framework will probably
set a preprocessor flag _RWSTD_NO_EXTERN_C_EXCEPTIONS. What exactly
would we do to prevent this from being a problem? I can think of two
things.
1. Add a try/catch block inside every once function definition
that might throw.
2. Implement our own pthread_once() type function that has C++
linkage and use it with all configurations on all platforms.
Both solutions are compatible with all systems, and would eliminate the
warning on MSVC as a side effect. Obviously the first option isn't that
pleasant because there is no _good_ way I can see to communicate a
failure back to the application. Is there something wrong with the
second option?
Good questions.
I suppose the potential overhead would be my biggest concern.
The solution we discussed recently on another list (overloading
pthread_once() for extern "C++" functions) involves dynamically
allocating a small chunk of memory. That's a steep price to pay
for one time initialization.
But we might be solving a non-issue. I'm not sure yet that there
are any one-time initializers in the library that can throw an
exception. So I think we're safe until we've actually found one
that does. Although it surely would be nice to have a robust
solution in place just in case we add an initializer that can
throw in the future.
Btw., there is another alternative: For compilers like MSVC
that ignore the difference between extern "C" and extern "C++"
functions (i.e., where _RWSTD_NO_EXTERN_C_COMPATIBILITY is
#undefined) we can just pass extern "C++" functions to
__rw_once().
Martin
