Confusion about static initialization for static members of templates

[originalfamousjohnsmith]

template <typename type> class SSmallMemory
{
protected:
   static SFixedAllocator classAllocator;
};	

template <typename type> SFixedAllocator SSmallMemory<type>::classAllocator = 
SFixedAllocator(sizeof(type), 1024);

I guess this is the thing I really dislike about C++, the core problem that keeps it from being easy to program in. It always seems to be my bane trying to keep things initialized properly without incurring too much overhead or going into awkward programming 'idioms' that are a pain to maintain.

I cut out the irrelevant part of the template so as not to get too off track.

Basically, what happens here? Is this safe to use in this manner or am I playing with fire? Though I've read a lot on this stuff and revisited it time and again I am not sure what happens here. Since anything using the template is going to include the header it's in, then will the allocator always be initialized before the class gets used, or am I living in a fantasy land to think so?

[originalfamousjohnsmith]

If it's not safe now, would chaging it to something like:
classAllocator = createClassAllocator() do the trick???

[superbonzo]

I've not a copy of the standard at my disposal now, but, if I remember well, class template static data members (excluding explcit specializations) have unordered initialization. Thus, your "allocator" will always be initialized before any SSMallMemory class instance only if there are no global/namespace/static class SSMallMemory variables.

[originalfamousjohnsmith]

Originally Posted by superbonzo

I've not a copy of the standard at my disposal now, but, if I remember well, class template static data members (excluding explcit specializations) have unordered initialization. Thus, your "allocator" will always be initialized before any SSMallMemory class instance only if there are no global/namespace/static class SSMallMemory variables.

Thank you for the reply, I have been sort of spinning in circles and gotten pretty confused. Sadly, that makes sense. I guess I will have to figure something better out.

Is there maybe some way within a header to force a call to an initializer method just by including it?

If I could do that somehow, I could make an init function for each object file. To my thinking at least, that would be a simple solution that makes the most sense, that doesn't introduce too much tricky code that either has overhead or is confusing to me.

Unfortunately, my preprocessor mojo is very weak.

[superbonzo]

if you allow the most general usage of the SSmallMemory class then probably the answer is negative (provided you won't use compiler specific settings...).

By the way, you might consider changing your design towards more C++ - like idioms such as policies, traits and similar.

That sead, you could also simply clearly specify in the documentation of the SSmallMemory class that no global/namespace/static instances of this class are allowed or that before any use of this class a specfic initializatin function should be called and so on... (take for example the Microsoft COM and its CoInitialize() function )

[originalfamousjohnsmith]

Well, I want to keep reasonably simple, and while I could generalize it it's for really a few specific tools and probably won't get released publicly unless I manage to finish a probably very overambitious project.

I guess I sort of want the best of both worlds, to use classes and templates as helpers but still manage to have great performance and simple design that's easy for me to understand and maintain, and maybe that's just not realistic.

If I can't force an actual call through the header files, I think I can still create one that calls all of them in the order I want and just manually call it in main. Not exactly elegant but hopefully it will get the job done.

[superbonzo]

I guess I sort of want the best of both worlds, to use classes and templates as helpers but still manage to have great performance and simple design that's easy for me to understand and maintain, and maybe that's just not realistic.

I hope you're not saying that using classes and templates prevents you from achieving "great performance and simple designs". Actually it's quite the contrary... ( if used properly, of course )

in any case, I forgot mentioning the possibility of wrapping your class declaration in an anonymous namespace; in this way everything will be local to the translation unit including your header file, thus enabling a finer control over initialization order ( but there are also other side effects, so it's not a good idea unless you know what you're doing... ).

[originalfamousjohnsmith]

Originally Posted by superbonzo

I hope you're not saying that using classes and templates prevents you from achieving "great performance and simple designs". Actually it's quite the contrary... ( if used properly, of course )

in any case, I forgot mentioning the possibility of wrapping your class declaration in an anonymous namespace; in this way everything will be local to the translation unit including your header file, thus enabling a finer control over initialization order ( but there are also other side effects, so it's not a good idea unless you know what you're doing... ).

I wouldn't say they prevent you from it, but any kind of metaprogramming is going to add a lot of complication let alone if you go into some of the harrier stuff. This is actually kind of a good case in point. I have a static generated for every class I want to use this allocator...but how do I initialize them all? I'd probably never try this without templates because the initialization need would be obvious up front and I'd know it would be a lot of hassle and would give it up quickly.

I do want to have a separate allocator for each class if I can manage it without causing problems because this will keep them together in memory, but now I have this weird dynamic static initialization thing to worry about, which makes me wonder if I made a mistake to try to use templates for this at all. I have looked at some of the andrescu stuff and I find it a little confusing and it looks like a lot of overhead. I am sure it's less than standard VC++ or even hoard but right now I have amazingy little overhead so I hate to change that if I can help it.

After a bit of thought, I realize I can't ever init them all automatically, either. Since it will get generated on the fly I can't ever know what will be using it beforehand for sure. So I'd have to remember to do it explicitly for each class, which I am sure would be doomed to failure.

EDIT: Ok, I see what you mean about the namespace thing.

If I understand right you declare it in its own namepsace, then when you say 'using namespace specialnamespace', after that point the variable is guaranteed to be initialized. That might be just what I am looking for. Thanks a lot - I have done much reading but that idea never came to me (or sunk in if I did see it elsewhere).

[laserlight]

Originally Posted by originalfamousjohnsmith

If I understand right you declare it in its own namepsace, then when you say 'using namespace specialnamespace', after that point the variable is guaranteed to be initialized.

Yes, except that you leave the selection of the name specialnamespace and the using directive to the compiler, i.e., it will be as if you had done that (but of course exactly how the compiler does it is implementation defined).

[originalfamousjohnsmith]

yes, thanks, that's right.

I just wanted to report this is working beautifully. Normally I work around it but now I know I can just do
namespace
{
long dummy = init();
}

and know everything will be exactly as I want. So many problems this would have solved if I'd know this trick years ago. Not to mention the guard variables.