Множественное наследование- 2

Одна если virtual наследование

Дык реализация-то одна.

Вот и ошибка

компилятор утверждает, что Foo в Derived не реализован

struct IBase { virtual void Foo() = 0; }; struct IDerived : public virtual IBase { virtual void Bar() = 0; }; class Base : public virtual IBase { virtual void Foo() { } }; class Derived : public Base, public IDerived { virtual void Bar() { } }; IDerived* Create() { return new Derived(); }

Два смещения в 2х таблицах виртуальных функций должно быть, компилятор не понимает где взять 2е - вот и ошибка

почему оно должно перекособочить? Или ты её напрямую читаешь?

да

кастую к конкретному интерфейсу и отдаю наружу

снаружи её НЕ плюсовый код читает

у меня тут ручная реализация COM в clang на макоси

не спрашивайте зачем, так надо

Два смещения в 2х таблицах виртуальных функций должно быть, компилятор не понимает где взять 2е - вот и ошибка

ок, согласен, разобрался

В общем, раскровило всё

У интерфейсов с наследованием через public virtual другой формат vtable

и что с этим делать не понятно

В общем, раскровило всё

Тупой вопрос - зачем наследоваться от интерфейсов виртуально? Виртуально есть смысл наследоваться от классов с данными чтобы не дублировать их.

В общем, раскровило всё

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

Тупой вопрос - зачем наследоваться от интерфейсов виртуально? Виртуально есть смысл наследоваться от классов с данными чтобы не дублировать их.

иерархия интерфейсов вида IUnknown -> IFoo -> IBar

при этом есть класс Foo, реализующий IFoo

если сделать класс Bar, наследующий Foo и пытающийся реализовать IBar

компилятору становится плохо

А в легаси можно написать функцию с такой же сигнатурой, НО ДРУГИМ ИМЕНЕМ, и в ней вызывать ту. А указатель взять от первой.

Мне нравится вариант с static_cast

иерархия интерфейсов вида IUnknown -> IFoo -> IBar

Ну сделайте тривиальные форвардеры если нужна предсказуемая таблица виртуальных функций? https://gcc.godbolt.org/z/FpINkq - пример от Анатолия без виртуального наследования.

иерархия интерфейсов вида IUnknown -> IFoo -> IBar

В целом же в COM ситуация такая же, но виртуальное наследование никто обычно не применяет. В ATL для борьбы с этим куча шаблонных хелперов :)

по старой памяти, подобные иерархии у меня в MSVC++6 работали

Гонишь....

Например IUnknown реализуется в CComObject, который параметризуется пользовательским классом.

Например IUnknown реализуется в CComObject, который параметризуется пользовательским классом.

Вот я его обычно и юзал для такой нарКОМании

Тупой вопрос - зачем наследоваться от интерфейсов виртуально? Виртуально есть смысл наследоваться от классов с данными чтобы не дублировать их.

Наоборот, нужно очень хорошо подумать, перед тем как наследоваться от данных. В большинстве случаев в такой ситуации лучше предпочесть композицю. А наследование интерфейсов позволяет отделить логику от собственно реализаций. Фигачишь логику с интерфейсами, и не паришься. Потом переезд на другие протоколы, новую бд, новую схему взаимодействия, и всё такое остаётся лишь вопросом имплементации конкретных интерфейсов.

Наоборот, нужно очень хорошо подумать, перед тем как наследоваться от данных. В большинстве случаев в такой ситуации лучше предпочесть композицю. А наследование интерфейсов позволяет отделить логику от собственно реализаций. Фигачишь логику с интерфейсами, и не паришься. Потом переезд на другие протоколы, новую бд, новую схему взаимодействия, и всё такое остаётся лишь вопросом имплементации конкретных интерфейсов.

Мы обсуждаем конкретно виртуальное наследование а не наследование вообще.

Мы обсуждаем конкретно виртуальное наследование а не наследование вообще.

пардон, не всё прочитал

так-то да, костыль костёлём погоняет.

Прогоню ереси: А хорошо в других языках придумали. Множественно наследуемся только от интерфейсов, а имплементации выносим отдельно. Вот бы и в ццп так.

Прогоню ереси: А хорошо в других языках придумали. Множественно наследуемся только от интерфейсов, а имплементации выносим отдельно. Вот бы и в ццп так.

Дык так тоже можно в цпп ж

оффтоп_мод_офф

Дык так тоже можно в цпп ж

можно.. Но только когда сам :)

Дык так тоже можно в цпп ж

У человека вот проблема на полдня

Да жди метаклассов чо

Да жди метаклассов чо

Метаклассы не помогут, это синтаксический сахар.

так жду, да =)

Прогоню ереси: А хорошо в других языках придумали. Множественно наследуемся только от интерфейсов, а имплементации выносим отдельно. Вот бы и в ццп так.

Так иди и пиши на других языках, кто держит то?

Прогоню ереси: А хорошо в других языках придумали. Множественно наследуемся только от интерфейсов, а имплементации выносим отдельно. Вот бы и в ццп так.

в дотнетах это сейчас ломают и можно будет прямо в интерфейсах писать реализацию

Так иди и пиши на других языках, кто держит то?

Как-то совсем не в тему ответ.

я не сталкивался с ситуацией, когда ромбовидное наследование реализаций было бы необходимо или удобно. А вот на проблемы с этим натыкался.

я не сталкивался с ситуацией, когда ромбовидное наследование реализаций было бы необходимо или удобно. А вот на проблемы с этим натыкался.

В стандартную библиотеку С++ давно заглядывал?

В стандартную библиотеку С++ давно заглядывал?

временами. А что там?

Потоки ввода-вывода...

Потоки ввода-вывода...

и в каком месте там необходимо ромбовидное наследование реализации?

Всем привет такой вопрос. Можно ли перебрать одновеменно два вектора примерно таким образом? for (auto var1, auto var2 : vector1, vector2) {}?

я не сталкивался с ситуацией, когда ромбовидное наследование реализаций было бы необходимо или удобно. А вот на проблемы с этим натыкался.

Вообще, очень странно даже читать такое. Я вообще в упор не понимаю, почему тонкости наследования должы быть как-то связаны с наличием или отсутствием данных в классе... Также, совсем не понимаю, почему нужно себя ограничивать линейным, единичным наследованием. Мир гораздо разнообразнее. Удалось тебе уложиться в линейную иерархию -- ну, очень здорово, классно! Я не буду форсить множественное наследование специально, чисто ради искусства. Но вот если НЕ удалось, что тогда ?

и в каком месте там необходимо ромбовидное наследование реализации?

Ну, изучи, исследуй, материалы знаешь где, наверное?

Всем привет такой вопрос. Можно ли перебрать одновеменно два вектора примерно таким образом? for (auto var1, auto var2 : vector1, vector2) {}?

можно через zip_iterator

Всем привет такой вопрос. Можно ли перебрать одновеменно два вектора примерно таким образом? for (auto var1, auto var2 : vector1, vector2) {}?

изкоробки - нельзя, нужна ranges-подобная библиотека с функцией наподобие zip

изкоробки - нельзя, нужна ranges-подобная библиотека с функцией наподобие zip

Это же в boost, да ?

Спасибо за ответы, почитаю

Это же в boost, да ?

не только, в Ranges-v3 помоему тоже есть, и гугл по запросу zip_iterator ещё всякую мелочёвку выдаёт

и в каком месте там необходимо ромбовидное наследование реализации?

Базовый класс потока, поток ввода, поток вывода, поток ввода вывода. Ты как Страуструпа не читал.

Базовый класс потока, поток ввода, поток вывода, поток ввода вывода. Ты как Страуструпа не читал.

читал. И код смотрел. Оно там есть, но не вижу в нём необходимости

читал. И код смотрел. Оно там есть, но не вижу в нём необходимости

Ну, ок

Всем привет такой вопрос. Можно ли перебрать одновеменно два вектора примерно таким образом? for (auto var1, auto var2 : vector1, vector2) {}?

Ну и напомню, что всё ещё можно написать простой цикл на основе индекса, а также использовать std::for_each + std::distance + std::advance. Последнее,конечно, по-уродски...

Ну и напомню, что всё ещё можно написать простой цикл на основе индекса, а также использовать std::for_each + std::distance + std::advance. Последнее,конечно, по-уродски...

Решил попробовать такое BOOST_FOREACH(boost::tuple<int,int> &p, zip_range(v1, v2)) { doSomething(p.get<0>(), p.get<1>()); }

Решил попробовать такое BOOST_FOREACH(boost::tuple<int,int> &p, zip_range(v1, v2)) { doSomething(p.get<0>(), p.get<1>()); }

А BOOST_FOREACH зачем?

А BOOST_FOREACH зачем?

Пока только такое нашел по своему запросу

Пока только такое нашел по своему запросу

range-for используй или std::for_each.

range-for используй или std::for_each.

Хорошо, сейчас почитаю. Спасибо еще раз)

Но вообще, ставь буст, алгоритмы, рэнжы...

Решил попробовать такое BOOST_FOREACH(boost::tuple<int,int> &p, zip_range(v1, v2)) { doSomething(p.get<0>(), p.get<1>()); }

если 17е плюсы, то с помощью structured bindings можно делать так: { auto [index, value] = p; doSomething(index, value); }

если 17е плюсы, то с помощью structured bindings можно делать так: { auto [index, value] = p; doSomething(index, value); }

А полностью напиши...

for (const boost::tuple<int,int> &p : zip_range(v1, v2)) { auto [index, value] = p; doSomething(index, value); } доволен?)

кстати так ещё нельзя? for (auto [index, value] : zip_range())

Всем привет такой вопрос. Можно ли перебрать одновеменно два вектора примерно таким образом? for (auto var1, auto var2 : vector1, vector2) {}?

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

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

Есть два вектора, их надо перебрать и сделать определенные действия над каждым элементом. Сейчас для этого есть два цикла. Я хотел это как то склеить

почему два, если один цикл должен быть?

Вообще, очень странно даже читать такое. Я вообще в упор не понимаю, почему тонкости наследования должы быть как-то связаны с наличием или отсутствием данных в классе... Также, совсем не понимаю, почему нужно себя ограничивать линейным, единичным наследованием. Мир гораздо разнообразнее. Удалось тебе уложиться в линейную иерархию -- ну, очень здорово, классно! Я не буду форсить множественное наследование специально, чисто ради искусства. Но вот если НЕ удалось, что тогда ?

ну я не только про данные. Данные — это так, индикатор, что пора задуматься, а не пытаешься ли ты натянуть стул на осла, из-за того, что у них по четыре ноги. Я больше про реализации. И там тонкости наследования и так очень зависят, вот например в случае разных реализаций с одинаковым интерфейсом. Короче, топлю за композицию реализаций. Интерфейсы смешиваешь как угодно, а реализации хранишь где-то отдельно. Так прозрачнее и более поддерживаемо.

почему два, если один цикл должен быть?

ПОтому что два вектора перебираются отдельно

по-моему, проще оставить 2 цикла..

или там действия одинаковые?

или там действия одинаковые?

Да, просто векторы разные

тогда нужен не zip, а какой-нибудь concat, который из двух векторов клеит новый вектор без копирования

или проще: вынести тело цикла в лямбду и сделать два цикла/два for_each

for (const boost::tuple<int,int> &p : zip_range(v1, v2)) { auto [index, value] = p; doSomething(index, value); } доволен?)

Не, не доволен. Зачем тут это? Можно либо сразу тапл в функцию передавать либо in-place при вызове выделять его элементы ... Короче и яснее. Я думал, там сразу в for_each можно, так, как ты написал, что ещё нельзя.

или проще: вынести тело цикла в лямбду и сделать два цикла/два for_each

По-моему хороший вариант

почему два, если один цикл должен быть?

for (int i = 0, j = 0; i < v1.size() || j < v2.size(); i++, j++)

for (int i = 0, j = 0; i < v1.size() || j < v2.size(); i++, j++)

for(size_t i = 0; i < std::min(v1.size(), v2.size()); ++i) ...

zip нужен в тех случаях, когда у нас 2 последовательности одинаковой длины и нужно совершить действие над каждой парой

zip нужен в тех случаях, когда у нас 2 последовательности одинаковой длины и нужно совершить действие над каждой парой

так у него как раз этот случай: есть vec1, vec2, и нужно for(i : ...) doSomething(vec1[i], vec2[i])

так у него как раз этот случай: есть vec1, vec2, и нужно for(i : ...) doSomething(vec1[i], vec2[i])

нет, у него doSomething(vec1[i]); doSomething(vec2[i]);

так у него как раз этот случай: есть vec1, vec2, и нужно for(i : ...) doSomething(vec1[i], vec2[i])

Никто не говорил, что длина одинаковая....

О, вы тут еще об этом говорите. Решили с коллегами оставить текущее решение с двумя циклами (не знаю почему, я просто ревьюил)

Никто не говорил, что длина одинаковая....

Длина разная была бы

О, вы тут еще об этом говорите. Решили с коллегами оставить текущее решение с двумя циклами (не знаю почему, я просто ревьюил)

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