Yuval Ronen wrote:
One more thing: using static data inside a function usually introduces thread-safety issues. I'm not sure if boost::array suffers from this, but I think it worth a check. If there is a problem, you might want to switch to native C++ arrays, or get some help from Jason's singleton...
First, we have to remember that boost::array pretends to be a POD type by not having any constructors or destructors. This means that a compiler might allocate the static in preset storage, thus removing all thread safety issues. I don't know if it's required to do so, though. If it doesn't, then the constructor for boost::array must be called and there are two scenarios. 1) The compiler generates a first_entry flag and sets it immediately upon entering. In this case, a thread might attempt to use the array before it's finished constructing. Access violations for the strings would be the result. 2) The compiler generates a statics_constructed that gets set after all constructors have finished. In this case, two threads might both try to construct the array. The trivial nature of boost::array means that there are no issues with this. I don't think any sane compiler would go for option 1, but I can't know for sure. Can anybody with the standard resolve the POD issue? If the compiler is required to allocate the array in preset storage, there are definitely no issues. Sebastian Redl