Jeffrey C. Gealow wrote:
>
> In article <4jckdc$ad6@engnews1.Eng.Sun.COM> clamage@Eng.Sun.COM
> (Steve Clamage) writes:
>
>    I believe a reasonable solution to the problem of initialization of
>    non-local static data is not to use non-local static data!
>
>    Instead of a static data object or static class data member, use a
>    function with a local static object.
>
> But this adds the overhead of the function call mechanism to every use
> of the object.
>

If you inline the function, are you guarenteed a
single instance, or might there be one in each
compilation unit, or in each invocation of the
function?

If it's safe, inlining the function would get rid
of the overhead, but I'm not sure of the safety ...


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

[c.s.c++ moderator's note: This thread has drifted away from the issue
of how the C++ standard should address initialization of global static
data.  I suggest that further discussion be conducted in
comp.lang.c++.moderated.  mha]

Jeffrey C. Gealow wrote:

In article <4jckdc$ad6@engnews1.Eng.Sun.COM> clamage@Eng.Sun.COM
(Steve Clamage) writes:

   I believe a reasonable solution to the problem of initialization of
   non-local static data is not to use non-local static data!

   Instead of a static data object or static class data member, use a
   function with a local static object.

But this adds the overhead of the function call mechanism to every use
of the object.


This may not be appropriate for this forum, but I have also found that
it will cause the heap to be corrupted if such a function is called in
a driver DLL under Win NT 3.51 and VC 4.0, although I have no idea
why.  Global statics don't seem to have the same limitation.

Regards,

Randal.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

      [ Articles to moderate: mailto:c++-submit@netlab.cs.rpi.edu ]
      [  Read the C++ FAQ: http://www.connobj.com/cpp/cppfaq.htm  ]
      [  Moderation policy: http://www.connobj.com/cpp/guide.htm  ]
      [      Comments? mailto:c++-request@netlab.cs.rpi.edu       ]

In article <4jckdc$ad6@engnews1.Eng.Sun.COM> clamage@Eng.Sun.COM
(Steve Clamage) writes:

   I believe a reasonable solution to the problem of initialization of
   non-local static data is not to use non-local static data!

   Instead of a static data object or static class data member, use a
   function with a local static object.

But this adds the overhead of the function call mechanism to every use
of the object.

Jeff
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

jgealow@mtl.mit.edu (Jeffrey C. Gealow) writes:

>In article <4jckdc$ad6@engnews1.Eng.Sun.COM> clamage@Eng.Sun.COM
>(Steve Clamage) writes:
>
>   I believe a reasonable solution to the problem of initialization of
>   non-local static data is not to use non-local static data!
>
>   Instead of a static data object or static class data member, use a
>   function with a local static object.
>
>But this adds the overhead of the function call mechanism to every use
>of the object.

A good compiler will inline the function, especially if you define
it as `inline' and put the function definition in the header file.
(If it is a non-member function, you need to declare it as `extern
inline' to ensure that you get one copy of the static object.)
Some compilers don't inline functions containing local static objects,
but it is certainly possible to do so; if you have such a compiler, you
should ask your compiler vendor to improve their compiler's inlining.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

kanze@gabi-soft.fr (J. Kanze) s'icrit :
> In article <4jckdc$ad6@engnews1.Eng.Sun.COM> clamage@Eng.Sun.COM (Steve
> Clamage) writes:
>
>     [...]
> |> I believe a reasonable solution to the problem of initialization of
> |> non-local static data is not to use non-local static data!
>
> |> Instead of a static data object or static class data member, use a
> |> function with a local static object.
>     [...]
> |> Only two features are missing, compared to non-local static objects:
>
> |> 1. If you never reference an object, it is never initialized.
>
> But is this guaranteed by the standard anyway?  I know that I have a
> significant number of static objects which must be initialized before
> main (but in any order), but I have always believed that this works
> because of the way current compilers work, and not because of anything
> in the standard.
>
> |> 2. The order of destruction remains unspecified. If that is a problem,
> |> possibly the static objects could be of a type which has a do-nothing
> |> destructor and a "destroy" member function which could be called
> |> explicitly at the proper time.
>
> I thought that the order of destruction was the reverse of
> initialization.  This is what it says in the January draft, at least.
> Has this been changed?

I think that the order of destruction of static objects is
unspecified, only because the order of construction is unspe-
cified.

Which ever order the compiler chooses, the order of destruction
of the same static objects MUST be the exact opposite of their
construction order ! This is compiler-dependent.

I suggest the standard allows for static class constructors to
remove this compiler dependence !
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article doh@arl-news-svc-2.compuserve.com, Philippe Verdy <100105.3120@compu
serve.com> writes:
>Many problems in C++ are related to the need of using some
>static members in the definition of the class.
>
>There are many cases where those static members have to be
>initialized in a proper sane order, as for any instances of
>the class they belong.
>
>Shamely, the current C++ definition does not allow for a clean
>specification of which (and when) classes are constructed
>prior to using them for the construction of other classes.

The lack of specification of initialization order across modules is
not due to lack of trying. Many proposals have been made, and none
have been considered adequate. Your proposal for metaclasses is too big
a change to be considered in this round of standardization.

I believe a reasonable solution to the problem of initialization of non-local
static data is not to use non-local static data!

Instead of a static data object or static class data member, use a
function with a local static object. Example:

T1& global_T1() { static t1(args); return t1; } // instead of T1 global_T1;

class C {
 static T2& static_T2(); // instead of T2 static_T2;
};
T2& C::static_T2() { static T2 t2; return t2; }

The only way to access static objects t1 or t2 is to call a function.
The first time the access function is called, the object is initialized
then, and only then. You have whatever control over the order of
initialization you need. Typically the order will be implicitly correct,
since no static data can be used until it is initialized.

Only two features are missing, compared to non-local static objects:

1. If you never reference an object, it is never initialized.

2. The order of destruction remains unspecified. If that is a problem,
possibly the static objects could be of a type which has a do-nothing
destructor and a "destroy" member function which could be called
explicitly at the proper time.
---
Steve Clamage, stephen.clamage@eng.sun.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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <4jckdc$ad6@engnews1.Eng.Sun.COM> clamage@Eng.Sun.COM (Steve
Clamage) writes:

    [...]
|> I believe a reasonable solution to the problem of initialization of
|> non-local static data is not to use non-local static data!

|> Instead of a static data object or static class data member, use a
|> function with a local static object.
    [...]
|> Only two features are missing, compared to non-local static objects:

|> 1. If you never reference an object, it is never initialized.

But is this guaranteed by the standard anyway?  I know that I have a
significant number of static objects which must be initialized before
main (but in any order), but I have always believed that this works
because of the way current compilers work, and not because of anything
in the standard.

|> 2. The order of destruction remains unspecified. If that is a problem,
|> possibly the static objects could be of a type which has a do-nothing
|> destructor and a "destroy" member function which could be called
|> explicitly at the proper time.

I thought that the order of destruction was the reverse of
initialization.  This is what it says in the January draft, at least.
Has this been changed?
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]