如何在一个列表中存储不同的数据类型?(C++)

2021-12-22 00:00:00 data-structures c++

我需要存储一个对象的各种属性的列表.属性由名称和数据组成，可以是任何数据类型.

I need to store a list of various properties of an object. Property consists of a name and data, which can be of any datatype.

我知道我可以创建一个Property"类，并使用不同的 PropertySubClass 对其进行扩展，这些 PropertySubClass 仅因它们存储的数据类型而异，但感觉不对.

I know I can make a class "Property", and extend it with different PropertySubClasses which only differ with the datatype they are storing, but it does not feel right.

class Property
{
     Property(std::string name);
     virtual ~Property();

     std::string m_name;
};

class PropertyBoolean : Property
{
     PropertyBoolean(std::string name, bool data);

     bool m_data;
};

class PropertyFloat : Property
{
     PropertyFloat(std::string name, float data);

     float m_data;
};

class PropertyVector : Property
{
     PropertyVector(std::string name, std::vector<float> data);

     std::vector<float> m_data;
};

现在我可以将各种属性存储在一个

Now I can store all kinds of properties in a

 std::vector<Property*>

为了获取数据，我可以将对象转换为子类.或者我可以创建一个纯虚函数来处理函数内部的数据，而无需进行强制转换.

and to get the data, I can cast the object to the subclass. Or I can make a pure virtual function to do something with the data inside the function without the need of casting.

无论如何，创建这些不同类型的子类的感觉并不正确，这些子类仅因它们存储的数据类型而异.有没有其他方便的方法来实现类似的行为?

Anyways, this does not feel right to create these different kind of subclasses which only differ by the data type they are storing. Is there any other convenient way to achieve similar behavior?

我无法访问 Boost.

I do not have access to Boost.

推荐答案

C++ 是一种多范式语言.在混合范式的地方，它最闪耀，最强大.

C++ is a multi-paradigm language. It shines brightest and is most powerful where paradigms are mixed. 

class Property
{
public:
    Property(const std::string& name) //note: we don't lightly copy strings in C++
      : m_name(name) {}
    virtual ~Property() {}
private:
    std::string m_name;
};

template< typename T >
class TypedProperty : public Property
{
public:
    TypedProperty (const std::string& name, const T& data)
      : Property(name), m_data(data);
private:
    T m_data;
};

typedef std::vector< std::shared_ptr<Property> > property_list_type;

<小时>

为什么使用 std::shared_ptr 而不是 Property*?
考虑这个代码:

Why using std::shared_ptr<Property> instead of Property*?
Consider this code: 

void f()
{
  std::vector<Property*> my_property_list;
  for(unsigned int u=0; u<10; ++u)
    my_property_list.push_back(new Property(u));

  use_property_list(my_property_list);

  for(std::vector<Property*>::iterator it=my_property_list.begin();
                                      it!=my_property_list.end(); ++it)
    delete *it;
}

那个 for 循环试图清理，删除向量中的所有属性，就在它超出范围并带走所有指针之前.
现在，虽然这对于新手来说可能看起来不错，但如果您只是一位经验丰富的 C++ 开发人员，那么一旦您看到该代码，就会引起警钟.

That for loop there attempts to cleanup, deleting all the properties in the vector, just before it goes out of scope and takes all the pointers with it.
Now, while this might seem fine for a novice, if you're an only mildly experienced C++ developer, that code should raise alarm bells as soon as you look at it.

问题是对 use_property_list() 的调用可能会引发异常.如果是这样，函数 f() 将立即离开.为了正确清理，将调用 f() 中创建的所有自动对象的析构函数.也就是说，my_property_list 将被正确销毁.std::vector 的析构函数会很好地清理它保存的数据.然而，它持有指针，std::vector如何知道这些指针是否是最后一个引用它们的对象?
由于它不知道，它不会删除对象，它只会在销毁其内容时销毁指针，从而在堆上留下您不再有任何指针指向的对象.这就是所谓的泄漏".

The problem is that the call to use_property_list() might throw an exception. If so, the function f() will be left right away. In order to properly cleanup, the destructors for all automatic objects created in f() will be called. That is, my_property_list will be properly destroyed. std::vector's destructor will then nicely cleanup the data it holds. However, it holds pointers, and how should std::vector know whether these pointers are the last ones referencing their objects?
Since it doesn't know, it won't delete the objects, it will only destroy the pointers when it destroys its content, leaving you with objects on the heap that you don't have any pointers to anymore. This is what's called a "leak".

为了避免这种情况，您需要捕获所有异常，清理属性，然后重新抛出异常.但是，十年后，有人必须为 10MLoC 应用程序添加一个新功能，这已经发展到，并且匆忙添加了在某些条件成立时过早地离开该功能的代码.代码经过测试，可以正常工作并且不会崩溃 - 只有它所在的服务器现在每小时泄漏几个字节，导致它由于大约每周一次内存不足而崩溃.发现这使得精细调试很多小时.

In order to avoid that, you would need to catch all exceptions, clean up the properties, and the rethrow the exception. But then, ten years from now, someone has to add a new feature to the 10MLoC application this has grown to, and, being in a hurry, adds code which leaves that function prematurely when some condition holds. The code is tested and it works and doesn't crash - only the server it's part of now leaks a few bytes an hour, making it crash due to being out of memory about once a week. Finding that makes for many hours of fine debugging.

底线:永远不要手动管理资源，始终将它们包装在旨在处理此类资源的一个实例的类的对象中.对于动态分配的对象，这些句柄称为智能指针"，最常用的是shared_ptr.

Bottom line: Never manage resources manually, always wrap them in objects of a class designed to handle exactly one instance of such a resource. For dynamically allocated objects, those handles are called "smart pointer", and the most used one is shared_ptr.

相关文章