强制静态成员初始化

发布于 2024-12-13 06:44:25 字数 692 浏览 1 评论 0原文

我有一个包含静态成员的类,即字符串到函数指针的映射。该映射旨在使用一组静态映射填充一次,并且随后不会被修改。

我的问题是,如何确保地图在初始化之前不被访问?我的代码目前看起来像这样:

class MyClass
{
  static MapType s_myMap;
public:
  static const MapType& getTheMap()
  {
    if (s_myMap.empty())
    {
      // Populate the map
    }
    return s_myMap;
  }
};

对于 MyClass 的外部客户端工作正常,但不会阻止内部类成员在初始化之前直接访问 private 映射。

为了解决这个问题,我正在考虑将映射设置为 getter 方法本地化:

class MyClass
{
public:
  static const MapType& getTheMap()
  {
    static MapType s_myMap;
    if (s_myMap.empty())
    {
      // Populate the map
    }
    return s_myMap;
  }
};

这是一个好主意,还是有更好的方法来实现这一点?

I have a class which contains a static member, a map of strings to function pointers. This map is intended to be populated once with a static set of mappings, and will not subsequently be modified.

My question is, how can I ensure the map is not accessed before it is initialised? My code currently looks something like this:

class MyClass
{
  static MapType s_myMap;
public:
  static const MapType& getTheMap()
  {
    if (s_myMap.empty())
    {
      // Populate the map
    }
    return s_myMap;
  }
};

which works fine for external clients of MyClass, but doesn't prevent internal class members from directly accessing the private map before it has been initialised.

To address that problem I am thinking of making the map local to the getter method:

class MyClass
{
public:
  static const MapType& getTheMap()
  {
    static MapType s_myMap;
    if (s_myMap.empty())
    {
      // Populate the map
    }
    return s_myMap;
  }
};

Is that a good idea, or is there a better way of achieving this?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

ら栖息 2024-12-20 06:44:25

将静态移入函数中将解决以下问题的任何顺序
初始化问题,但它可能会给你留下一个命令
毁灭一.在许多情况下,最好使用指针
动态分配,使地图永不破坏。

至于初始化它,我经常使用两个迭代器构造函数,所以
我可以使地图本身成为常量。为此,只需定义一个
带有转换运算符的 struct ,例如:

struct MapInitData
{
    char const* key;      //  Or whatever type is needed.
    char const* value;    //  Or whatever type is needed.
    operator MapType::value_type() const
    {
        return MapType::value_type( key, value );
    }
};

MapInitData const mapInitTable[] =
{
    { "key1", "value1" },
    //  ...
};

MapType const ourMap( begin( mapInitTable ), end( mapInitTable ) );

Moving the static into the function will solve any order of
initialization problems, but it may leave you with an order of
destruction one. In many cases, it's preferable to use a pointer and
dynamic allocation, so that the map is never destructed.

As for initializing it, I often use the two iterator constructor, so
that I can make the map itself const. To do this, just define a
struct with a conversion operator, something like:

struct MapInitData
{
    char const* key;      //  Or whatever type is needed.
    char const* value;    //  Or whatever type is needed.
    operator MapType::value_type() const
    {
        return MapType::value_type( key, value );
    }
};

MapInitData const mapInitTable[] =
{
    { "key1", "value1" },
    //  ...
};

MapType const ourMap( begin( mapInitTable ), end( mapInitTable ) );
你与清晨阳光 2024-12-20 06:44:25

您可以为此集合声明一个类并将其填充到构造函数中。

You can declare a class for this collection and populate it in constructor.

嘿哥们儿 2024-12-20 06:44:25

如果 MyClass::getTheMap() 没有在全局/namespace范围内调用,那么你不必担心static数据成员在初始化之前使用。

但是,如果上面的静态方法 getTheMap() 用于全局/命名空间范围:

SomeGlobal object = MyClass::getTheMap();

那么您当前的方法似乎没问题。

If MyClass::getTheMap() is not called in global / namespace scope, then you don't have to worry about the static data member being used before it's initialized.

However if, the above static method getTheMap() is used in global / namespace scope:

SomeGlobal object = MyClass::getTheMap();

then your current approach seems to be fine.

<逆流佳人身旁 2024-12-20 06:44:25

为了线程安全,你的函数“getTheMap”应该有一个锁。将其移至函数本地是一个好主意。

我认为这与 drdobbs 文章“C++ and The Perils of Double-Checked Locking”http://drdobbs 相关。 com/cpp/184405726 与问题类似。在这里,他介绍了不同类型的单例和单例的用例和安全性。其他具有线程安全的模式。

至于销毁,需要销毁吗?

your function 'getTheMap' should have a lock in it for thread safety. Moving it local to the function is a good idea.

I think that this is related to the drdobbs article "C++ and The Perils of Double-Checked Locking" http://drdobbs.com/cpp/184405726 is similar to the question. Here he goes through use cases and safety of different types of singleton & other patterns with threadsafety.

as far as destruction, do you need to destroy it?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文