c++对象模型的缺点.解决方案是什么?

c++ object model disadvantage. What is the solution?

本文关键字：是什么 解决方案 缺点 对象模型 c++      更新时间：2023-10-16

我正在学习c++。在阅读c++对象模型内部时，我理解了不同的对象模型。

1)简单对象模型。

2)表驱动对象模型。

3) c++对象模型。

问题:

"它的主要缺点是需要重新编译未修改的代码，这些代码使用了类的对象，而该类的非静态数据成员已经被添加、删除或修改。"

我理解了上面的陈述。类定义中发生的任何更改使用相同类的源代码需要重新编译。

意味着，在不重新编译的情况下也可以实现相同的效果。怎么做呢?如果有人能提供样例代码，那就太好了。我在Linux/Ubuntu中使用g++。

在修改类时防止重新编译的典型习惯用法是PImpl。

http://en.wikipedia.org/wiki/Opaque_pointer C.2B.2B

在其他语言/对象模型中可能有方法实现相同的功能，但在c++中没有。否则，这就不是c++对象模型的缺点了。

然而，减轻后果是可能的，例如:(1)只导出库中的接口，也就是纯抽象类;(2)从不更改已发布的接口。如果必须添加新的API，则通过新的接口导出它(即使它引用的是旧的/修改的实现类)。

我不确定代码示例会有多大帮助。这不是一种编码技术。如果你知道什么是纯抽象类，你就知道了。

请注意，在头文件中公开实现细节可能有好处，但缺点是在细节发生变化时强制重新编译;函数可以更容易地内联，这可以提高运行时性能。你需要决定在什么地方，什么时候，这种取舍是值得的。

通过引入额外的间接层，可以将所有私有实现细节隐藏在源文件中。一种常见的方法是指针到私有实现(或"pimpl")习惯用法，例如:

// Header file
class Thing {
public:
    Thing(...);
    ~Thing();
    // Public interface
private:
    struct Impl;
    std::unique_ptr<Impl> impl;
};
// Source file
struct Thing::Impl {
    // private details
};
Thing(...) : impl(new Impl(...)) {}
~Thing() {}
// Implementation of public interface

另一种可能性是定义一个抽象接口，用一个或多个工厂来创建包含实现的具体实例，例如:

// Header file
class Thing {
public:
    virtual ~Thing() {}
    static std::unique_ptr<Thing> make(...);
    // Pure virtual public interface
};
// Source file
class ThingImpl : public Thing {
    // Implementation of public interface
    // Private implementation details
};
std::unique_ptr<Thing> Thing::make(...) {
    return std::unique_ptr<Thing>(new ThingImpl(...));
}

这两种方法都将所有实现细节放在源文件中，因此当细节发生变化时，只有源文件才需要重新编译。但两者都引入了额外的指针间接和/或间接函数调用，这可能会影响运行时性能。

相关文章：