Error 'int SS::f(void)': overloaded function differs only by return type from 'void SS::f(void)'
Error 'SS::f': redefinition; different basic types
Error 'SS::f': overriding virtual function return type differs and is not covariant from 'S1::f'
Error 'int SS::f(void)': overloaded function differs only by return type from 'void SS::f(void)'
Error 'SS::f': redefinition; different basic types
Error 'SS::f': overriding virtual function return type differs and is not covariant from 'S1::f'
И? Как она должна была бы вести себя в этом классе?
C>Error 'int SS::f(void)': overloaded function differs only by return type from 'void SS::f(void)'
C>Error 'SS::f': redefinition; different basic types
C>Error 'SS::f': overriding virtual function return type differs and is not covariant from 'S1::f'
Что ты хотел этим выразить: ты не понимаешь, почему возникает эта ошибка, или спрашиваешь, как это можно обойти?
--
Не можешь достичь желаемого — пожелай достигнутого.
Error 'SS::f': overriding virtual function return type differs and is not covariant from 'S1::f'
Error 'SS::f': method with override specifier 'override' did not override any base class methods
Здравствуйте, Caracrist, Вы писали:
R>>Что ты хотел этим выразить: ты не понимаешь, почему возникает эта ошибка, или спрашиваешь, как это можно обойти?
C>Спрашиваю как можно обойти.
Можно сделать промежуточные классы, реализовать f в них, и унаследоваться от них:
Других путей не вижу. Может, мегамозги что-нибудь и придумают еще
Но вообще, странная ситуация. Я вовсю использую интерфейсы, и никогда не попадал на такое — обычно методы имеют более осмысленное имя, которое не совпадает ни с чем другим, или у методов разные наборы входных параметров
Здравствуйте, Marty, Вы писали:
M>Но вообще, странная ситуация. Я вовсю использую интерфейсы, и никогда не попадал на такое — обычно методы имеют более осмысленное имя, которое не совпадает ни с чем другим, или у методов разные наборы входных параметров
Я мог бы SomeGetterImpl поставить мембером, но тогда изза enable_shared_from_this мне придется держать его в поинтере, что добавит лишнюю аллокацию (или 2).
Напрямую, не через интерфейс, с этим классом никто не работает.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, RonWilson, Вы писали:
RW>>мне хотелось, чтобы ТС объяснил как теперь это вызывать
J>Очевидно, по указателю на один из интерфейсов
Здравствуйте, Caracrist, Вы писали:
C>кто "она"? Это две разные функции разных интерфейсов от которых по стечению обстоятельств наследует этот класс.
А твоя проблема в чём? Просто не переопределяй эти функции в этом классе...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Marty, Вы писали:
M>Но вообще, странная ситуация. Я вовсю использую интерфейсы, и никогда не попадал на такое — обычно методы имеют более осмысленное имя, которое не совпадает ни с чем другим, или у методов разные наборы входных параметров
Ну, например при COW, метод Release может возвращать счётчик, а может не возвращать.
Или, в одном интерфейсе метод может иметь тип void, а в другом возвращать код ошибки и т. д...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Caracrist, Вы писали:
C>Здравствуйте, Marty, Вы писали:
M>>Но вообще, странная ситуация. Я вовсю использую интерфейсы, и никогда не попадал на такое — обычно методы имеют более осмысленное имя, которое не совпадает ни с чем другим, или у методов разные наборы входных параметров
C>Вот примерно такое у меня: C>
C>Я мог бы SomeGetterImpl поставить мембером, но тогда изза enable_shared_from_this мне придется держать его в поинтере, что добавит лишнюю аллокацию (или 2). C>Напрямую, не через интерфейс, с этим классом никто не работает.
Я не понял, почему так важно IGetter и enable_shared_from_this объединить в одном классе (SomeGetterImpl) — ведь именно это объединение мешает сделать SomeGetterImpl членом, вместо того, чтобы наследоваться от него. Но, не вдаваясь в эти подробности, один из варантов обхода (эскизно) мог бы выглядеть так:
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
M>>Но вообще, странная ситуация. Я вовсю использую интерфейсы, и никогда не попадал на такое — обычно методы имеют более осмысленное имя, которое не совпадает ни с чем другим, или у методов разные наборы входных параметров
E>Ну, например при COW, метод Release может возвращать счётчик, а может не возвращать.
Ну, у меня все Release'ы от одного базового интерефейса, всегда счетчик возвращают
E>Или, в одном интерфейсе метод может иметь тип void, а в другом возвращать код ошибки и т. д...
У меня практически все методы возвращают коды ошибок, иное только в случае очень специфичных условий