Можно ли принудительно определить конкретный конструктор с помощью интерфейса? - PullRequest
2 голосов
/ 06 мая 2019

Я хочу создать интерфейс - абстрактный класс, который, среди прочего, обеспечивает производные классы (т. Е. Соответствующие интерфейсу) для предоставления конкретного конструктора.

Что-то вроде:

class IComClient
{
public:
    virtual IComClient(int _id, TBaseCom*_com) = 0;
    virtual void task() = 0;
private:
    int id;
    TBaseCom* com;
);

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

Есть ответ для C # но такая же ситуация в C ++?

Ответы [ 2 ]

1 голос
/ 06 мая 2019

Нет способа обеспечить существование определенного конструктора для производных классов в базовом классе.

Вы можете принудительно установить существование конкретного конструктора, пытаясь вызвать этот конструктор или используя static_assert.

Нечто подобное может быть достигнуто не базовым классом, а с использованием мета-класса ... если они приняты в язык в будущем стандарте.

0 голосов
/ 06 мая 2019

Интерфейсы существуют, так что старый код может вызывать новый код . Вы пишете интерфейс, который обеспечивает функцию, скажем foo(). Я могу написать код, который вызывает foo() сейчас , хотя реализации foo() пока не существует. Он сможет вызывать любые будущие реализации foo(), написанные задолго до того, как я уйду на свою виллу на Багамские острова.

Если вы объявите, что все будущие потомки вашего класса будут реализовывать конструктор по умолчанию, эта информация для меня бесполезна. Я не могу создать экземпляры класса, который еще не написан! Что мне или кому-либо еще, кто не видел потомка вашего класса, делать с вашим объявлением?

Если есть пользователь A, который хочет создать потомка вашего класса, и пользователь B, который хочет создать экземпляр класса A, то пусть они сами решат, как это сделать лучше всего. Вы не являетесь участником их сделки.

Но подождите минутку, я могу своего рода конструировать экземпляры класса, который еще не был написан! Мне нужно написать шаблон, создать объект внутри, и кто-то создаст его экземпляр своим классом. Но тогда я просто могу использовать конструктор по умолчанию, и это использование заставит любого, кто хочет создать экземпляр моего шаблона, реализовать конструктор по умолчанию.

Конечно, вы не можете заставить никого создать экземпляр вашего шаблона. Если пользователям это нужно, они будут реализовывать нужный вам конструктор. Если они не нуждаются в ваших услугах, лучше не говорите им, что делать.

...