Re: static object in a function: what if the constructor throws?
On 15 Mai, 23:57, Krzysztof Czainski <1czaj...@gmail.com> wrote:
[code]
class Singleton
{
Singleton(); // may throw
public:
static Singleton& getInstance()
{
static Singleton instance;
return instance;
}
//...
};
int main()
{
try {
Singleton& s = Singleton::getInstance();
//...
}
catch(...) { /* ... */ }}
[/code]
Is it legal for the static variable constructor to throw?
Yes, see [stmt.dcl]/4:
"[..] If the initialization exits by throwing an exception, the
initialization is not complete, so it will be tried again the
next time control enters the declaration. If control re-enters
the declaration (recursively) while the object is being initialized,
the behavior is undefined."
Would it
throw during the first call to getInstance, or earlier, or is it
unspecified when? Maybe someone has some other comments on this
implementation of the Singleton pattern?
PODs are required to be initialized statically here, same p.:
"The zero-initialization (8.5) of all local objects with static
storage duration (3.7.1) is performed before any other initialization
takes place. A local object of POD type (3.9) with static storage
duration initialized with constant-expressions is initialized before
its block is first entered.[..]"
but your class cannot be a POD, because it has a non-trivial c'tor.
The short and simple answer would be to say your Singleton c'tor
throws when control enters the declaration as described above.
Alas, the standard gives some freedom to implementations here,
and this is described in the middle part of above paragraph:
"[..] An implementation is permitted to perform early initialization
of other local objects with static storage duration under the same
conditions that an implementation is permitted to statically
initialize an object with static storage duration in namespace scope
(3.6.2). Otherwise such an object is initialized the first time
control passes through its declaration; such an object is considered
initialized upon the completion of its initialization.[..]"
Note that the first reference to "other" has to be compared with
the local objects of POD type mentioned above. This might indeed
be a problem, if I read the standard right here. Let's consider
such an implementation and the fact that Singleton throws an exception
during construction. This time it happens during the static
initialization
time but there is no current scope which might catch this exception
so we would end up in undefined behavior similar to that of
non-local static objects. Currently I see nothing in the conditions
of the relevant section [basic.start.init]/2 which would exclude
my scenario. Although the recent draft N2588 has added several
new wordings, I still see the same potential problem.
Anyone else who wants to comment on this?
Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]