Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Early dynamic initialization permitted for local statics?

Reply
Thread Tools

Early dynamic initialization permitted for local statics?

 
 
Triple-DES
Guest
Posts: n/a
 
      05-28-2008
I've seen this question raised more than once, but I have not yet seen
a definite, conclusive answer. Consider the following code:

struct C {
C() {} // might throw
};

int main() {
try {
static C c;
}
catch(...) {
//...
}
}

Now according to 6.7/4:
"(...) 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).(...)"

Are the following statements correct?
1)
An implementation may perform early initialization of c, possibly
resulting in an uncaught exception.

2)
Early initialization can be prevented by making C::C() modify an
arbitrary object of namespace scope with static storage duration, per
3.6.2/2

Thanks in advance.
DP
 
Reply With Quote
 
 
 
 
Bo Persson
Guest
Posts: n/a
 
      05-28-2008
Triple-DES wrote:
> I've seen this question raised more than once, but I have not yet
> seen a definite, conclusive answer. Consider the following code:
>
> struct C {
> C() {} // might throw
> };
>
> int main() {
> try {
> static C c;
> }
> catch(...) {
> //...
> }
> }
>
> Now according to 6.7/4:
> "(...) 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).(...)"


This talks about statically initializing with a constant expression.
As your example involves a constructor, this is more likely a dynamic
initlialization.

The static keyword doesn't help.

>
> Are the following statements correct?
> 1)
> An implementation may perform early initialization of c, possibly
> resulting in an uncaught exception.


I don't think so.

>
> 2)
> Early initialization can be prevented by making C::C() modify an
> arbitrary object of namespace scope with static storage duration,
> per
> 3.6.2/2


No.


The other question is why you need a static variable inside main()?!
As main can only be called once, there is little risk of initializing
the local variable more than once.



Bo Persson



 
Reply With Quote
 
 
 
 
Triple-DES
Guest
Posts: n/a
 
      05-29-2008
On 28 Mai, 20:09, "Bo Persson" <(E-Mail Removed)> wrote:
> Triple-DES wrote:
> > struct C {
> > *C() {} // might throw
> > };

>
> > int main() {
> > *try {
> > * *static C c;
> > *}
> > *catch(...) {
> > * //...
> > *}
> > }

>
> > Now according to 6.7/4:
> > "(...) 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).(...)"

>
> This talks about statically initializing with a constant expression.
> As your example involves a constructor, this is more likely a dynamic
> initlialization.
>


Sure, I have considered that interpretation. But see for instance this
thread:
http://groups.google.com/group/comp....9a16407c86419a

Notably, the comment by Francis W. Glassborow:
(...)And I would much prefer that it was not allowed to do dynamic
initialisation early, not least because of implications on exception
safety.(...)

> The static keyword doesn't help. *

[snip]
> The other question is why you need a static variable inside main()?!
> As main can only be called once, there is little risk of initializing
> the local variable more than once.


That's just to illustrate the problem.

DP
 
Reply With Quote
 
Irin Kotchencko
Guest
Posts: n/a
 
      05-29-2008
> Triple-DES wrote:
>> I've seen this question raised more than once, but I have not yet
>> seen a definite, conclusive answer. Consider the following code:
>>
>> struct C {
>> C() {} // might throw
>> };
>>
>> int main() {
>> try {
>> static C c;
>> }
>> catch(...) {
>> //...
>> }
>> }
>>


Interestingly, if:

void f() {
static C aC;
/* ... */
}

If the ctor throws an exception, when f called the second time, C ctor
is called again. At least in my implementation.

Is this behavior specified in the standard and can I rely on it ?
 
Reply With Quote
 
Triple-DES
Guest
Posts: n/a
 
      05-29-2008
On 29 Mai, 07:38, Irin Kotchencko <(E-Mail Removed)> wrote:
> Interestingly, if:
>
> void f() {
> * * static C aC;
> * * /* ... */
>
> }
>
> If the ctor throws an exception, when f called the second time, C ctor
> is called again. At least in my implementation.
>
> Is this behavior specified in the standard and can I rely on it ?


Yes, this is also specified in 6.7/4:
"(...)If the initialization exits by throwing an exception, the
initialization is not complete, so it will be tried again next time
control enters the declaration(...)"

DP
 
Reply With Quote
 
Irin Kotchencko
Guest
Posts: n/a
 
      05-29-2008
> On 29 Mai, 07:38, Irin Kotchencko <(E-Mail Removed)> wrote:
>> Interestingly, if:
>>
>> void f() {
>> static C aC;
>> /* ... */
>>
>> }
>>
>> If the ctor throws an exception, when f called the second time, C ctor
>> is called again. At least in my implementation.
>>
>> Is this behavior specified in the standard and can I rely on it ?

>
> Yes, this is also specified in 6.7/4:
> "(...)If the initialization exits by throwing an exception, the
> initialization is not complete, so it will be tried again next time
> control enters the declaration(...)"
>
> DP

thank you
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Are actions permitted on rising *and* falling edge of clock? Anon Anon VHDL 2 05-25-2007 01:00 PM
Unable to serialize the session state. Please note that non-serializable objects or MarshalByRef objects are not permitted when session state mode is 'StateServer' or 'SQLServer'. Mike Larkin ASP .Net 1 05-23-2005 12:33 PM
bit-fields and permitted types (and [OT] gcc) Chris McDonald C Programming 1 04-18-2005 12:33 PM
Multiple definitions of a variable in C++ not permitted Charles L C++ 5 02-08-2005 12:13 PM
why a ctor-like method is permitted? Lee Java 3 02-05-2004 07:37 PM



Advertisments