Здравствуйте, Максим Рогожин, Вы писали:

МР>Здравствуйте, AlexGin, Вы писали:

AG>>У класса может быть только один деструктор!

МР>Спасибо! А вот так можно делать?
...
ИМХО — неудачный дизайн архитектуры проекта, я бы не советовал так делать
Например: у нас есть сервер БД и специализированный сервер, выполняющий некую обработку наших запросов.

И там и там есть метод, выполняющий подсоединение: Connect()
Для меня НЕ ясно — к чему подсоединяется объект типа твоего SomeClass — к серверу Базы Данных, или к спец-серверу?

В общем:
Компилятор — тебя поймёт, но коллеги по проекту (а возможно — ты же сам, через полгода-год) будут плеваться...
...
МР>Тут все то же самое что и с деструкторами? Метод doSomething() можно вызывать через любой интерфейс? Не зависимо от того на каком месте он в интерфейсах объявлен?
Неоднозначности для компилятора — не будет, компилятор такой код успешно проглотит.
Для понимания остальными разработчиками в команде (да и тобой самим через пару месяцев после сдачи проекта) —
подобные решения будут могут восприниматься неоднозначно:

Так, если оба интерфейса имеют одноименный мембер, то — зачем наследовать от обоих?

Может быть — удачнее было бы отнаследоать новый интерфейс (назовем его Interface1Cool):

class Interface1 {
public:
    virtual ~Interface1() {}         // vtbl[0]
    virtual void doSomething() = 0;  // vtbl[1] Такой же как и в Interface2, но на первой позиции в vtbl
    virtual void doSomething1() = 0; // vtbl[2]

};

class Interface1Cool : public Interface1
{
     virtual void doSomethingCool() = 0; 
    virtual void doSomething2() = 0;
};

class SomeClass : public Interface1Cool
{
public:
    ~SomeClass() {};                   
    void doSomething1() override;      
    void doSomething2() override;      
    void doSomething() override;  
    void doSomethingCool() override;     
                   //...
};

Здравствуйте, Максим Рогожин, Вы писали:

МР>Здравствуйте, AlexGin, Вы писали:

AG>>У класса может быть только один деструктор!

МР>Спасибо! А вот так можно делать?
...
ИМХО — неудачный дизайн архитектуры проекта, я бы не советовал так делать
Например: у нас есть сервер БД и специализированный сервер, выполняющий некую обработку наших запросов.

И там и там есть метод, выполняющий подсоединение: Connect()
Для меня НЕ ясно — к чему подсоединяется объект типа твоего SomeClass — к серверу Базы Данных, или к спец-серверу?

В общем:
Компилятор — тебя поймёт, но коллеги по проекту (а возможно — ты же сам, через полгода-год) будут плеваться...
...
МР>Тут все то же самое что и с деструкторами? Метод doSomething() можно вызывать через любой интерфейс? Не зависимо от того на каком месте он в интерфейсах объявлен?

Ещё раз подчеркну: неоднозначности для компилятора — не будет, компилятор такой код успешно проглотит.

Так, если оба интерфейса имеют одноименный мембер, то — зачем наследовать от обоих?

Может быть — удачнее было бы отнаследоать новый интерфейс (назовем его Interface1Cool):

class Interface1 {
public:
    virtual ~Interface1() {}         // vtbl[0]
    virtual void doSomething() = 0;  // vtbl[1] Такой же как и в Interface2, но на первой позиции в vtbl
    virtual void doSomething1() = 0; // vtbl[2]

};

class Interface1Cool : public Interface1
{
    virtual void doSomethingCool() = 0; 
    virtual void doSomething2() = 0;
};

class SomeClass : public Interface1Cool
{
public:
    ~SomeClass() {};                   
    void doSomething1() override;      
    void doSomething2() override;      
    void doSomething() override;  
    void doSomethingCool() override;     
                   //...
};

P.S. В данном вопросе — множественного наследования интерфейсов вполне можно избежать,
что только поспособствует повышению читабельности кода и упрощению работы с твоим проектом