Topic: Static Initialization Question


Author: kanze@gabi-soft.de
Date: Sun, 15 Oct 2000 00:45:49 GMT
Raw View
Scott Meyers <smeyers@aristeia.com> writes:

|>  Two people have now written to me pointing out that 9.4.2/2 indicates=
 that
|>  a static data member of a class is initialized at namespace scope.
|>  However, 9.4.2/2 also explains that any initializer is in the scope o=
f the
|>  class, so in the following,

|>    int Widget::x =3D f();

|>  x is at namespace scope, but the call to f() is in the scope of Widge=
t.
|>  Sigh. =20

|>  Are there other places in this wacky language where the scope
|>  changes in the middle of a statement, or at least a non-compound
|>  statement?

After every use of operators ., -> and ::.  I think in some cases of
template lookup, too; IIRC, templates are always looked up in namespace
scope.

--=20
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]





Author: "Mark Rodgers" <mark.rodgers@cadenza.co.nz>
Date: 2000/10/08
Raw View
"Scott Meyers" <smeyers@aristeia.com> wrote in message
news:MPG.1446fbadeafde69c98974a@news.supernews.com...
> Well, I thought I understood the rules governing initialization of
nonlocal
> statics, but, having no life, I found myself reading 3.6.2/1, and suddenly
> this jumped out at me:
>
>   Objects with static storage duration DEFINED IN NAMESPACE SCOPE in the
>   same translation unit and dynamically initialized shall be initialized
in
>   the order in which their definition appears in the translation unit.
>
> The emphasis is mine, because that's the part that caught my attention.
If
> I read it correctly, that means that we know *nothing* about the order in
> which class statics requiring dynamic initialization will be initialized,
> not with respect to one another and not with respect to other nonlocal
> statics defined in the same translation unit.

We do.  Have a read of 9.4.2/2.  Class statics are defined at a
namespace scope, so the above paragraph applies to them too.  I guess
you could say they are declared at class scope, but it is the
definition that is all important.

Mark


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]






Author: Gabriel Dos Reis <gdr@codesourcery.com>
Date: 2000/10/08
Raw View
Scott Meyers <smeyers@aristeia.com> writes:

| Well, I thought I understood the rules governing initialization of nonlocal
| statics, but, having no life, I found myself reading 3.6.2/1, and suddenly
| this jumped out at me:
|
|   Objects with static storage duration DEFINED IN NAMESPACE SCOPE in the
|   same translation unit and dynamically initialized shall be initialized in
|   the order in which their definition appears in the translation unit.
|
| The emphasis is mine, because that's the part that caught my attention.  If
| I read it correctly, that means that we know *nothing* about the order in
| which class statics requiring dynamic initialization will be initialized,
| not with respect to one another and not with respect to other nonlocal
| statics defined in the same translation unit.  Consider:
|
|   struct Widget {
|     Widget();
|     static Widget sw1;
|     static Widget sw2;

There are declarations at class scope.

|   };
|
|   Widget w;                 // w is a nonlocal static at namespace scope
|                             // requiring dynamic initialization
|
|   Widget Widget::sw1(w);    // sw1 is a nonlocal static at class scope
|                             // requiring dynamic initialization

This is a definition at namespace scope.

|   Widget Widget::sw2(sw1);  // so is sw2

So is sw2.

| Until my recent rereading of 3.6.2/1, I though we knew that the order of
| initialization of w, sw1, and sw2 was the order of their definition,

That, still, is the case.

| ... but
| since sw1 and sw2 are at class scope and not namespace scope, it now looks
| like that is not true.

Their definitions are at namespace scope, the order of their
initialisations is covered by 3.6.2/1

| ...  I liked my old understanding better than my new
| understanding.  Is my new understanding correct?

I too like your old understanding because it is right :-))
The relevant chapter and verse are 9.4.2/2:

  The declaration of a static data member in its class definition is
  not a definition and may be of an incomplete type other that
  cv-qualified void.  The definition for a static data member shall
  appear in a namespace scope enclosing the member's class
  definition. [...]

--
Gabriel Dos Reis, gdr@codesourcery.com
CodeSourcery, LLC  http://www.codesourcery.com
       http://www.codesourcery.com/gcc-compile.shtml

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]






Author: Scott Meyers <smeyers@aristeia.com>
Date: 2000/10/08
Raw View
Two people have now written to me pointing out that 9.4.2/2 indicates that
a static data member of a class is initialized at namespace scope.
However, 9.4.2/2 also explains that any initializer is in the scope of the
class, so in the following,

  int Widget::x = f();

x is at namespace scope, but the call to f() is in the scope of Widget.
Sigh.

Are there other places in this wacky language where the scope changes in
the middle of a statement, or at least a non-compound statement?

Thanks,

Scott

--
I've scheduled more public seminars.  Check out
http://www.aristeia.com/seminars/ for details.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]






Author: comeau@panix.com (Greg Comeau)
Date: 2000/10/08
Raw View
In article <MPG.1446fbadeafde69c98974a@news.supernews.com>,
Scott Meyers  <smeyers@aristeia.com> wrote:
>Well, I thought I understood the rules governing initialization of nonlocal
>statics, but, having no life, I found myself reading 3.6.2/1, and suddenly
>this jumped out at me:
>
>  Objects with static storage duration DEFINED IN NAMESPACE SCOPE in the
>  same translation unit and dynamically initialized shall be initialized in
>  the order in which their definition appears in the translation unit.
>
>The emphasis is mine, because that's the part that caught my attention.  If
>I read it correctly, that means that we know *nothing* about the order in
>which class statics requiring dynamic initialization will be initialized,
>not with respect to one another and not with respect to other nonlocal
>statics defined in the same translation unit.  Consider:
>
>  struct Widget {
>    Widget();
>    static Widget sw1;
>    static Widget sw2;
>  };
>
>  Widget w;                 // w is a nonlocal static at namespace scope
>                            // requiring dynamic initialization
>
>  Widget Widget::sw1(w);    // sw1 is a nonlocal static at class scope
>                            // requiring dynamic initialization
>
>  Widget Widget::sw2(sw1);  // so is sw2
>
>Until my recent rereading of 3.6.2/1, I though we knew that the order of
>initialization of w, sw1, and sw2 was the order of their definition, but
>since sw1 and sw2 are at class scope and not namespace scope, it now looks
>like that is not true.  I liked my old understanding better than my new
>understanding.  Is my new understanding correct?

I call this jumping-at-shadow-reading. :) I do it all the time too :)

IMO, your original understanding is correct and you're reading
too much into DEFINED IN NAMESPACE SCOPE.  That is, yes,
sw1 and sw2 are clearly Widget::'d, and so reenter Widget scope,
even though their definitions are sytactically disjoint.
Nevertheless, their definitions _appear_ in namespace scope,
and that's what the passage means (at least as I read it,
IOWS, IMO, DEFINED == WHOSE DEFINITIONS APPEAR)

If nothing else, check 9.4.2/7.

Also, the 3.6.2/1 passage that you quote is not talking about
static data memebers but statics in general.

- Greg
--
Comeau Computing / Comeau C/C++ ("so close" 4.2.44 betas starting)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]






Author: kanze@gabi-soft.de
Date: 2000/10/08
Raw View
Scott Meyers <smeyers@aristeia.com> writes:

|>  Well, I thought I understood the rules governing initialization of
|>  nonlocal statics, but, having no life, I found myself reading
|>  3.6.2/1, and suddenly this jumped out at me:

|>    Objects with static storage duration DEFINED IN NAMESPACE SCOPE in
|>    the same translation unit and dynamically initialized shall be
|>    initialized in the order in which their definition appears in the
|>    translation unit.

|>  The emphasis is mine, because that's the part that caught my
|>  attention.  If I read it correctly, that means that we know
|>  *nothing* about the order in which class statics requiring dynamic
|>  initialization will be initialized, not with respect to one another
|>  and not with respect to other nonlocal statics defined in the same
|>  translation unit.  Consider:

|>    struct Widget {
|>      Widget();
|>      static Widget sw1;
|>      static Widget sw2;
|>    };

|>    Widget w;                 // w is a nonlocal static at namespace sc=
ope=20
|>                              // requiring dynamic initialization

|>    Widget Widget::sw1(w);    // sw1 is a nonlocal static at class scop=
e
|>                              // requiring dynamic initialization

|>    Widget Widget::sw2(sw1);  // so is sw2

|>  Until my recent rereading of 3.6.2/1, I though we knew that the
|>  order of initialization of w, sw1, and sw2 was the order of their
|>  definition, but since sw1 and sw2 are at class scope and not
|>  namespace scope, it now looks like that is not true.  I liked my old
|>  understanding better than my new understanding.  Is my new
|>  understanding correct?

No.  The names *have* class scope, but they are *defined* in namespace
scope.

--=20
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]






Author: "Mark Rodgers" <mark.rodgers@cadenza.co.nz>
Date: 2000/10/09
Raw View
"Scott Meyers" <smeyers@aristeia.com> wrote in message
news:MPG.144854e61c75dd1f98974b@news.supernews.com...
> Are there other places in this wacky language where the scope changes in
> the middle of a statement, or at least a non-compound statement?

It's a general feature of class members - c.f. 9.3/5.

The weird thing is that given

  struct X
  {
     typedef int T;
     void f(T t);
     T g();
     static T x;
  };

I can write

  void X::f(T t) {}

but not

  T X::g() { return 0; }

It has to be

  X::T X::g() { return 0; }

So the scope really does begin in the middle of the statement, just
as it does with static data members.  This is similar to the fact
that you can't write

  T X::x = T();

The second T is OK, but the first is not.  It has to be

  X::T X::x = T();

Mark


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]






Author: wmm@fastdial.net
Date: 2000/10/09
Raw View
In article <MPG.1446fbadeafde69c98974a@news.supernews.com>, Scott Meyers
<smeyers@aristeia.com> writes:
>Well, I thought I understood the rules governing initialization of nonlocal
>statics, but, having no life, I found myself reading 3.6.2/1, and suddenly
>this jumped out at me:
>
>  Objects with static storage duration DEFINED IN NAMESPACE SCOPE in the
>  same translation unit and dynamically initialized shall be initialized in
>  the order in which their definition appears in the translation unit.
>
>The emphasis is mine, because that's the part that caught my attention.  If
>I read it correctly, that means that we know *nothing* about the order in
>which class statics requiring dynamic initialization will be initialized,
>not with respect to one another and not with respect to other nonlocal
>statics defined in the same translation unit.  Consider:
>
>  struct Widget {
>    Widget();
>    static Widget sw1;
>    static Widget sw2;
>  };
>
>  Widget w;                 // w is a nonlocal static at namespace scope
>                            // requiring dynamic initialization
>
>  Widget Widget::sw1(w);    // sw1 is a nonlocal static at class scope
>                            // requiring dynamic initialization
>
>  Widget Widget::sw2(sw1);  // so is sw2
>
>Until my recent rereading of 3.6.2/1, I though we knew that the order of
>initialization of w, sw1, and sw2 was the order of their definition, but
>since sw1 and sw2 are at class scope and not namespace scope, it now looks
>like that is not true.  I liked my old understanding better than my new
>understanding.  Is my new understanding correct?

No.  Static data members _are_ "defined in namespace scope" -- see
9.4.2p2:

        The declaration of a static data member in its class
        definition is not a definition... The definition for a
        static data member shall appear in a namespace scope
        enclosing the member   s class definition.

Including static data members is exactly the reason for using the
"defined in namespace scope" wording.

-- William M. Miller


 -----  Posted via NewsOne.Net: Free (anonymous) Usenet News via the Web  -----
  http://newsone.net/ -- Free reading and anonymous posting to 60,000+ groups
               NewsOne.Net is FOR SALE.  Click below for details.
       http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=446657012

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]






Author: Scott Meyers <smeyers@aristeia.com>
Date: 2000/10/06
Raw View
Well, I thought I understood the rules governing initialization of nonlocal
statics, but, having no life, I found myself reading 3.6.2/1, and suddenly
this jumped out at me:

  Objects with static storage duration DEFINED IN NAMESPACE SCOPE in the
  same translation unit and dynamically initialized shall be initialized in
  the order in which their definition appears in the translation unit.

The emphasis is mine, because that's the part that caught my attention.  If
I read it correctly, that means that we know *nothing* about the order in
which class statics requiring dynamic initialization will be initialized,
not with respect to one another and not with respect to other nonlocal
statics defined in the same translation unit.  Consider:

  struct Widget {
    Widget();
    static Widget sw1;
    static Widget sw2;
  };

  Widget w;                 // w is a nonlocal static at namespace scope
                            // requiring dynamic initialization

  Widget Widget::sw1(w);    // sw1 is a nonlocal static at class scope
                            // requiring dynamic initialization

  Widget Widget::sw2(sw1);  // so is sw2

Until my recent rereading of 3.6.2/1, I though we knew that the order of
initialization of w, sw1, and sw2 was the order of their definition, but
since sw1 and sw2 are at class scope and not namespace scope, it now looks
like that is not true.  I liked my old understanding better than my new
understanding.  Is my new understanding correct?

Scott

--
I've scheduled more public seminars.  Check out
http://www.aristeia.com/seminars/ for details.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]






Author: Herb Sutter <hsutter@peerdirect.com>
Date: 2000/10/08
Raw View
Scott, the text you want is in 9.4.2/2, which clarifies what's meant
here:

  ... The  definition  for  a  static  data member shall appear in a
  namespace scope enclosing the member's class definition.  In the defi-
  nition at namespace scope, the name of the static data member shall be
  qualified by its class name using the ::  operator. ...

So class statics are defined at namespace scope, and all is well with
the world.

Scott Meyers <smeyers@aristeia.com> writes:
>  Objects with static storage duration DEFINED IN NAMESPACE SCOPE in the
>  same translation unit and dynamically initialized shall be initialized in
>  the order in which their definition appears in the translation unit.
[...]
>The emphasis is mine, because that's the part that caught my attention.  If
>I read it correctly, that means that we know *nothing* about the order in
>which class statics requiring dynamic initialization will be initialized,
>not with respect to one another and not with respect to other nonlocal
>statics defined in the same translation unit.  Consider:
>
>  struct Widget {
>    Widget();
>    static Widget sw1;
>    static Widget sw2;
>  };

Note for other readers (I know Scott knows this): The above is a
DEFINITION for struct Widget, but only a DECLARATION for its constructor
and two static members. The following are DEFINITIONS for the two static
members, and they are at namespace scope:

[...]
>  Widget Widget::sw1(w);    // sw1 is a nonlocal static at class scope
>                            // requiring dynamic initialization
>
>  Widget Widget::sw2(sw1);  // so is sw2

Herb

---
Herb Sutter (mailto:hsutter@peerdirect.com)

CTO, PeerDirect Inc. (http://www.peerdirect.com)
Contributing Editor, C/C++ Users Journal (http://www.cuj.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]