Сохранение ABI, а также наличие правильного конструктора - PullRequest
0 голосов
/ 15 мая 2019

В настоящее время я пишу разделяемую библиотеку и использую подход PIMPL.Чтобы объяснить проблему, вот пример кода:

Message.h

class CMessage
{
public:
    CMessage();
    ~CMessage();
    void setType();
    void setData();
private:
    class CMessageInfo;
    std::unique_ptr<CMessageInfo> __msgInfo;
};

Message.cpp

struct CMessage::CMessageInfo
{
    unsigned int msgType;
    std::string msgData;
}

CMessage():__msgInfo(new CMessageInfo())
{
}

void CMessage::setType(unsigned int msgType) 
{
    __msgInfo.msgType = msgType;
}

void CMessage::setData(const std::string& data) 
{
    __msgInfo.data =data
} // don't want separate copy assignment and don't want to write this in CMessage constructor in header file

Основная проблема у меня заключается в том, что данные от пользователявсегда будет присваиваться внутреннему элементу данных с помощью оператора копирования.Я подумал о том, чтобы иметь это в конструкторе сообщений, чтобы при его вызове его данные конструктора impl можно было назначать напрямую, чтобы элемент строки данных создавался и инициализировался одновременно.

Таким образом, строкаБудет вызван конструктор, а не его оператор присваивания, но это создает другую проблему.Если я передам элемент данных в конструктор сообщений, то если завтра я добавлю элемент данных, подобный этому, и добавлю его в конструктор, то это может нарушить существующий код ABI.Можете ли вы предложить, как подойти к этой проблеме, чтобы у нас не было ненужных зависимостей компиляции и эффективности?

...