Hi there. responding to your points in turn... For statics defined in different translation units, my solution guarantees order of construction at a class level, rather than at object level, by expressing the dependency at class scope. This is the real issue I was trying to address. The example includes this concept, but not in an explicit way (it's simple concept that's difficult to express with a simple example). I guess my document didn't get this across as well as it could have. This solution allows translation units to be added (or removed) as required while preserving such relationships. My solution uses smart pointers to access objects (something the compiler will hopefully optimise away), but does not define the means by which such objects are constructed - this is an implementation detail supplied by the Structor-traits class, which includes the option of using static data instances in member (or static member or non-member) functions, or boost::call_once as possible solutions. If the standard specifies that static objects are destroyed in strict reverse order to construction then your solution is fine with me, although (obviously) it doesn't guarantee that the objects are destroyed before main() exits, which is useful for exception handling, not to mention debugging. Regards, Philip Ashmore. ----- Original Message ----- From: "bill_kempf" To: Sent: Thursday, March 21, 2002 5:10 PM Subject: [Boost-Users] Re: Fw: Boost.Threads thread_specific_ptr and more

--- In Boost-Users@y..., "Philip Ashmore" wrote:

...

Oops! I didn't know I had to join the group!

It's not a have to kinda thing. I was only suggesting that your questions/comments could be useful to the community and so would be "better" in this forum then just in private e-mail. You do have the choice, and I will respond to personal e-mails :).

...

Regards, Philip Ashmore ----- Original Message ----- From: "Philip Ashmore" To: "William Kempf" Cc: Sent: Wednesday, March 20, 2002 12:29 PM Subject: Re: Boost.Threads thread_specific_ptr and more

...

Hi there.

Rather than respond to your points directly, I've written a

document

...

...

outlining my ideas on how static data could be managed more clearly. This obviously relates to thread_specific_ptr as instances are global, hence static, but is quite general and therefore hopefully more useful.

Just for other peoples knowledge the attached document can now be found in the files section at http://groups.yahoo.com/group/Boost- Users/files/staticData.doc.

I'm not sure that you fully understand the problem your trying to solve by the document's text, so just let me make sure we're on the same page. Your initial example that's supposed to illustrate something that doesn't work, actually does work in some cases. Here's some complete code from your example that will compile, link and run, even using MSVC++ 6 SP 5.

#include <iostream>

class A { public: A() : val(0) { } int val; };

class B { public: static A g_a; };

A B::g_a;

static B g_b;

int main(int argc, char* argv) { std::cout << B::g_a.val << std::endl; std::cout << g_b.g_a.val << std::endl; return 0; }

The problem you allude to when you say "the order of construction of non-trivial static objects is seemingly arbitrary" actually only applies when the "statics" are defined in different translation units (which you do mention later in the article, so maybe you do understand the issue... I just need to make sure we're on the same page). Section 3.6.2 in the standard defines all of this. This is a well known "problem" for which there isn't any single solution... though there is one solution that's often preferred. Your complex template approach *almost* uses this solution, but not quite.

Your templates define smart pointers that lazily create the object on the heap the first time they are needed, and delete the object when the template goes out of scope. There are two problems I see with this. First, using the heap isn't always a good solution. Second, this approach doesn't address the issue with the order of destruction of the objects, which is the inverse problem with the order of construction.

The more traditional solution doesn't use the heap and should also address the issue of the order of destruction. All that's needed is to replace the data with a function!

A& g_a() { static A instance; return instance; }

This takes advantage of the rules for initialization order of local statics. In fact, the recommended way to use call_once() for globals makes use of this technique:

A* a = 0; boost::once_flag once_a = BOOST_ONCE_INIT; void init_a() { static A instance; a = &instance; } A& get_a() { boost::call_once(&init_a, once_a); return *a; }

Bill Kempf

Info: http://www.boost.org Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl Unsubscribe: mailto:boost-users-unsubscribe@yahoogroups.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/