Мне слух режет когда вместо шаблона говорят дженерик Думаю скоро привыкну

Просто шарписты и джависты так говорят, ибо в их ЯП так называется.

Просто шарписты и джависты так говорят, ибо в их ЯП так называется.

Просто шарписты и джависты так говорят, ибо в их ЯП так называется.

то есть ты всерьёз считаешь что множественное наследование реализации - это нормально и надо так делать? мда

и это в 2017 когда все поняли что вообще наследование (не говоря даже о множественном) создаёт не меньше проблем чем решает

Любопытно, что в dash документации нет даже упоминания interface, когда он в c++ есть, по крайней мере в VisualStudio. Да и куда ни глянь, редко где приводится

interface это COM-фича, в стандартном C++ такого ключевого слова нет. Документация верна; в портабельном коде не стоит этим пользоваться.

В принципе не плохо, по моему

У них там просто #define interface class, по-моему. А код дополнительно анализируется какой-то тулой, чтоб эти интерфейсы оборачивать в TLB.

Ну наверно не совсем так, там нельзя private определять и реализацию

непортабельные расширения - "В принципе не плохо"? Что вообще тогда плохо в этом мире?

По-моему, совсем так. Ты можешь что угодно наделать в этом «интерфейсе», а отвечать потом будешь перед TLB и COM-инфраструктурой. С точки зрения С++ этот код будет валидным.

Ещё более глубокие глубины ада.

Я бы такое в современном коде не советовал использовать. Придерживайся стандарта, это максимально безопасно.

есть objC++, вот уж где ад

ну и зачем там множественное наследование?

class basic_string_stream : public std::basic_istream, public std::basic_ostream

даже обычное наследование почти не применимо, а уж множественное наследование - тем более

Мне кажется, это какой то вопрос вкуса, что ли, или метода мышления, иначе споров на эту тему было бы, наверно, намного меньше

Хорошая штука

про чё там?

Патерны ооп, применимые к производству игр

templates > generics

есть objC++, вот уж где ад

Оксана читайте правила чата, пожалуйста!

а где всякие вакансии и обсуждение офесного планктона?

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

Есть места где множественное наследование ну прям напрашивается. Например делаете вы обработчик сообщений. В зависимости от чего-то там, у вас на вход могут сообщения приходить по разным протоколам, уходить по другим протоколам. Ну и напрашивается - сдалть базовый класс, сделать N классов принимающих сообщения, M классов отправляющих сообщения. Множественным наследованием всё это связать и получить NxM классов. Но проблема в том, что вам необходимо наследоваться от базового класса виртуально. Это может быть ощутимым ударом по производительности, если в большинстве вызовов используется именно базовый класс. Так что смотрите и выбирайте сами - между удобством и производительностью. Ну и общая рекомендация - если можно обойтись композицией вместо наледования - выбирайте композицию.