ИМХО можно сделать virtual void foo (/*variable amount of args*/) = 0, а в потомках делать assert'ы на количество и типы аргументов.

Вряд ли кто-то понял, чего тебе в самом деле хочется.

assert'ы на количество и типы аргументов

Что-то это как-то некрасиво. Должно же быть нечто более элегантное...

Именно вот так никак.

Вряд ли кто-то понял

У меня есть интерфейс, в нем метод. В зависимости от реализации количество и типы аргументов этого метода могут быть различными. Это как-то обобщается шаблонами/еще чем-то, чего я не знаю?

Не надо так делать. Вообще.

Что-то это как-то некрасиво. Должно же быть нечто более элегантное...

Не думаю.
Кстати, с assert'ами на типы могут быть вопросы.
Вот еще вариант, в конце статьи: http://nerdparadise.com/forum/openmic/5712/

Еще вариант

Есть еще мысль. Ты ж можешь в FirstGraph, SecondGraph делать наследуемую foo private, а вместо нее объявить функции c другим количеством аргументов.

Если будет ругаться, я бы сделал через промежуточный класс, чтобы не было конфликтов. Или, еще вариант из той же серии - изначально сделать foo-variardic private и объявить друзей.

Пробуй.

Погоди! Если у тебя прям вот так, то всё совсем просто:

class IGraph {
public:
    virtual void foo(int id) { throw logic_error("Error in source code"); }
    virtual void foo(int id, unsigned int weight) { throw logic_error("Error in source code"); }
};
 
class FirstGraph : public IGraph {
public:
    void foo(int id) {/*some code*/}
};
 
class SecondGraph : public IGraph {
public:
    void foo(int id, unsigned int weight) {/*some code*/}
};

У меня есть интерфейс, в нем метод. В зависимости от реализации количество и типы аргументов этого метода могут быть различными. Это как-то обобщается шаблонами/еще чем-то, чего я не знаю?

Это явно не всё, что тебе надо. Но, если делать буквально то, что ты изложил: делаешь метод с единственным аргументом, который является sum type всех комбинаций параметров.

У меня есть интерфейс ... В зависимости от реализации количество и типы аргументов этого метода могут быть различными

У тебя нет интерфейса, тебе показалось. Интерфейс абстрагирует реализации в обобщённое API, а не делает наоборот. Может быть тебе нужно иметь метод void foo(int, unsigned) и воторой аргумент в реализациях обрабатывать ~ по желанию.

Если у тебя прям вот так

Это явно не всё, что тебе надо

Нет, все же не совсем. Вся проблема в том, что реализации интерфейса IGraph буду писать не я и я понятия не имею, сколько аргументов захотят добавить в ф-цию foo(), помимо первого - id.

... реализации интерфейса IGraph буду писать не я и я понятия не имею, сколько аргументов захотят добавить ...

Нужно все дополнительные аргументы заворачивать в структуру которую и будут дальше расширать. Либо передавать вместо неё другой интерфейс из геттеров, типа void foo(int, Opts&) или void foo(int, IOpts&)

А тогда зачем тебе вообще объявлять foo в родительском классе?

Вся фишка ООП в том, что некая функция будет получать на вход IGraph и сможет вызвать foo, и это будет абсолютно корректно отработано вне зависимости от реального типа объекта (главное чтобы это был наследник IGraph). А в твоём случае код, работающий с экземляром IGraph так сделать не может и ему необходимо сначала как-то понять, какой же на самом деле класс ему дали (с помощью RTTI или дополнительного виртуального метода, который возвращает разные значения в разных классах наследниках). А если класс известен, то что мешает сделать static_cast к нужному типу и уже вызвать foo с нужными параметрами? При этом виртуальность нафиг не нужна.

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

Ты просто не понимаешь базовые концепции ООП и поэтому хочешь сделать то, чего C++ не умеет и не должен.

Или можешь заменить std::map<std::string, std::string> на std::unordered_map<int, std::experimental::any>

Вместо std::experimental::any можешь заюзать любую другую имплементацию «variant», или даже просто void* (что не C++-стиль).

Нужно все дополнительные аргументы заворачивать в структуру

Спасибо.

virtual void foo(IParams&)

Но это все равно говнокод и ты что то делаешь сильно не так и язык тут не причём.

Опять хочется странного

Тогда можете почитать: Дж. Толкиен «Хоббит или туда и обратно», Ричард Бах «Чайка по имени Джонатан Ливингстон», рассказы Александра Грина («Алые паруса», «100 верст по реке», «Корабли в Лиссе», «Комендант порта», «Бегущая по волнам»), Джером К. Джером «Трое в лодке, не считая собаки,», «Трое на 4-х колесах», Антуан де Сент Экзюпери «Маленький принц», Льюис Кэрролл «Алиса в стране чудес», «Алиса в Зазеркалье».

Получается у FirstGraph::foo один набор аргументов, у SecondGraph::foo другой и вызывающая функция должна знать foo какого класса она вызывает. Зачем при таком раскладе виртуальность?

Может тогда так?

class IGraph {
public:
    virtual void foo() = 0;
};
 
class FirstGraph : public IGraph {
private:
    int id;
public:
    FirstGraph(int id): id(id) {}
    void foo() {/*some code*/}
};
 
class SecondGraph : public IGraph {
private:
    int id;
    unsigned int weight;
public:
    SecondGraph(int id, unsigned int weight): id(id), weight(weight) {}
    void foo() {/*some code*/}
};

template<typename ... args>
class IGraph {
public:
    virtual void foo(args...) = 0;
};

class FirstGraph : public IGraph<int> {
public:
    void foo(int id)override {/*some code*/}
};

class SecondGraph : public IGraph<int,unsigned int> {
public:
    void foo(int id, unsigned int weight)override {/*some code*/}
};

?

Ага и кастовать в IGraph<...>* из void*.

Ну и нафига тут виртуальные функции? IGraph тут просто излишен.

Ну хотели же странного, нате