zero initialization.

[werasm]

Hi all,

I recently just stumbled upon this code. According to what
I see in the standard it should be fine, but I've always done
the initialization explicitly myself:

//.h
//...
struct X
{
static Y* m_Y;
};

//.cpp
//To initialise...
Y* X::m_Y; //...1
//as opposed to...
Y* X::m_Y = NULL; //...2

I now know (1) is correct as well (from various areas in the
standard).
I personally prefer (2) - probably because I've always done it that
way (I think I might have even had a problem with (1) a couple
of years back).

Any thoughts on this? Do I understand the standard correctly if I
say (1) is OK?

My rationale from std98:
- 8.5:5 - to zero initialize...
- 3.6.2 - storage for objects with static storage...

Which method do you consider preferred, or is it a matter of taste?

Regards,

Werner

[Rahul]

On Dec 19, 10:16 pm, werasm <[e-mail]:

Hi all,

I recently just stumbled upon this code. According to what
I see in the standard it should be fine, but I've always done
the initialization explicitly myself:

//.h
//...
struct X
{
static Y* m_Y;

};

//.cpp
//To initialise...
Y* X::m_Y; //...1

I think static variables stored in the data segment bss, are always
initialized with 0...
just like global variables...

//as opposed to...
Y* X::m_Y = NULL; //...2

I now know (1) is correct as well (from various areas in the

[Victor Bazarov]

Rahul wrote:

On Dec 19, 10:16 pm, werasm <[e-mail]:

>Hi all,

I recently just stumbled upon this code. According to what
I see in the standard it should be fine, but I've always done
the initialization explicitly myself:

//.h
//...
struct X
{
static Y* m_Y;

};

//.cpp
//To initialise...
Y* X::m_Y; //...1

I think static variables stored in the data segment bss, are always
initialized with 0...

To clarify...

It is unspecified what "segment" they are stored in, and there is no
reference to "bss" in the C++ language standard. Objects with static
storage duration have their memory zero-initialised before any other
dynamic initialisation takes place. If no other initialisation is
expected, the zero-filled memory is it.

just like global variables...

Global variables (declared at the namespace level) all have static
storage duration (if they have storage at all, that is).

>//as opposed to...
Y* X::m_Y = NULL; //...2

I now know (1) is correct as well (from various areas in the

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[jg]

On Dec 19, 9:16 am, werasm <[e-mail]:

>
Which method do you consider preferred, or is it a matter of taste?

I think that (2) is preferred. A 'static member' means that all
objects
of X shares the same member. The 'static' here does not require
that 'my_Y' be in static storage, although it is in fact true in many
implementations.

JG

[Victor Bazarov]

jg wrote:

On Dec 19, 9:16 am, werasm <[e-mail]:

>>
Which method do you consider preferred, or is it a matter of taste?

I think that (2) is preferred. A 'static member' means that all
objects
of X shares the same member. The 'static' here does not require
that 'my_Y' be in static storage, although it is in fact true in many
implementations.

I am not sure what "be in static storage" means here. Static class
data members are said to have static storage duration (see Standard,
[basic.stc.static]/4). Does that mean that they are "in static
storage"? Probably. If their storage has duration that is static,
then you can call their storage "static", and since those objects
are _in_ their storage, then it's OK to say that they are "in static
storage".

So, to argue, the Standard clearly _requires_ that static data
members "be in static storage". It has to be true for all compiler
implementations, otherwise they are not conforming.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[jg]

On Dec 19, 11:06 am, "Victor Bazarov" <[e-mail]:

>

I think that (2) is preferred. A 'static member' means that all
objects
of X shares the same member. The 'static' here does not require
that 'my_Y' be in static storage, although it is in fact true in many
implementations.

I am not sure what "be in static storage" means here. Static class
data members are said to have static storage duration (see Standard,
[basic.stc.static]/4). Does that mean that they are "in static
storage"? Probably. If their storage has duration that is static,

Yes, this was what I meant.

then you can call their storage "static", and since those objects
are _in_ their storage, then it's OK to say that they are "in static
storage".

So, to argue, the Standard clearly _requires_ that static data
members "be in static storage".

You're probably right. The 9.4.2.6 says it has external linkage.
Does it mean it is definitely a static/global, so it shall be
automatically zero-initialized ?

JG

[jg]

On Dec 19, 12:10 pm, jg <[e-mail]:

>
You're probably right. The 9.4.2.6 says it has external linkage.
Does it mean it is definitely a static/global, so it shall be
automatically zero-initialized ?

I found the answer for myself, 3.7.1(4) states a static member has
static storage duration.

Back to the original question, I think it is better to use
explicit initialization.

JG

[Daniel T.]

werasm <we****@gmail.comwrote:

I recently just stumbled upon this code. According to what
I see in the standard it should be fine, but I've always done
the initialization explicitly myself:

//.h
//...
struct X
{
static Y* m_Y;
};

//.cpp
//To initialise...
Y* X::m_Y; //...1
//as opposed to...
Y* X::m_Y = NULL; //...2

I now know (1) is correct as well (from various areas in the
standard).
I personally prefer (2) - probably because I've always done it that
way (I think I might have even had a problem with (1) a couple
of years back).

Any thoughts on this? Do I understand the standard correctly if I
say (1) is OK?

My rationale from std98:
- 8.5:5 - to zero initialize...
- 3.6.2 - storage for objects with static storage...

Which method do you consider preferred, or is it a matter of taste?

Guru's generally recommend making things explicit in code rather than
leaving them implicit, so your (2) would be the preferred thing to do.

[Pete Becker]

On 2007-12-19 16:22:44 -0500, "Daniel T." <da******@earthlink.netsaid:

werasm <we****@gmail.comwrote:

>I recently just stumbled upon this code. According to what
I see in the standard it should be fine, but I've always done
the initialization explicitly myself:

//.h
//...
struct X
{
static Y* m_Y;
};

//.cpp
//To initialise...
Y* X::m_Y; //...1
//as opposed to...
Y* X::m_Y = NULL; //...2

I now know (1) is correct as well (from various areas in the
standard).
I personally prefer (2) - probably because I've always done it that
way (I think I might have even had a problem with (1) a couple
of years back).

Any thoughts on this? Do I understand the standard correctly if I
say (1) is OK?

My rationale from std98:
- 8.5:5 - to zero initialize...
- 3.6.2 - storage for objects with static storage...

Which method do you consider preferred, or is it a matter of taste?

Guru's generally recommend making things explicit in code rather than
leaving them implicit, so your (2) would be the preferred thing to do.

Yes, there are "gurus" who don't believe that programmers ought to be
held to professional standards. So they tell us you shouldn't leave
static data implicitly initialized, because someone reading your code
might not know what that means, or, worse, might know what it means,
but think that you might not know what it means, and that you only got
the right result by accident.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

[werasm]

On Dec 19, 11:04 pm, Pete Becker <[e-mail]:

On 2007-12-19 16:22:44 -0500, "Daniel T." <[e-mail]:

werasm <[e-mail]:

I recently just stumbled upon this code. According to what
I see in the standard it should be fine, but I've always done
the initialization explicitly myself:

//.h
//...
struct X
{
static Y* m_Y;
};

//.cpp
//To initialise...
Y* X::m_Y; //...1
//as opposed to...
Y* X::m_Y = NULL; //...2

I now know (1) is correct as well (from various areas in the
standard).
I personally prefer (2) - probably because I've always done it that
way (I think I might have even had a problem with (1) a couple
of years back).

Any thoughts on this? Do I understand the standard correctly if I
say (1) is OK?

My rationale from std98:
- 8.5:5 - to zero initialize...
- 3.6.2 - storage for objects with static storage...

Which method do you consider preferred, or is it a matter of taste?

Guru's generally recommend making things explicit in code rather than
leaving them implicit, so your (2) would be the preferred thing to do.

Yes, there are "gurus" who don't believe that programmers ought to be
held to professional standards. So they tell us you shouldn't leave
static data implicitly initialized, because someone reading your code
might not know what that means, or, worse, might know what it means,
but think that you might not know what it means, and that you only got
the right result by accident.

Hmmm, does this mean you also suggest the latter?

Regards,

Werner

[Daniel T.]

Pete Becker <pe**@versatilecoding.comwrote:

"Daniel T." <da******@earthlink.netsaid:

Guru's generally recommend making things explicit in code rather
than leaving them implicit.

Yes, there are "gurus" who don't believe that programmers ought to
be held to professional standards. So they tell us you shouldn't
leave static data implicitly initialized, because someone reading
your code might not know what that means, or, worse, might know
what it means, but think that you might not know what it means, and
that you only got the right result by accident.

Much like the common recommendation that one should never put leading
underscores on variable names simply because in some contexts such a
variable is reserved.

The less context dependent a rule is, the easier it is to remember. "int
foo = 0;" makes 'foo' equal 0 no matter the context, for "int foo;",
'foo' will equal 0 in some contexts and be undefined in others.

But I take your point that some Guru's tend to talk down to people.