не важно короче)

CMAKE_CXX_COMPILER_ID == "GNU" && CMAKE_CXX_STANDARD == 11 CMAKE_CXX_EXTENSIONS=OFF => -std=c++11 CMAKE_CXX_EXTENSIONS=ON => -std=gnu++11

ну дааа... и что

ну дааа... и что

то

cmake же умеет VC++ использовать?

да

но для GNU конпилера именно такие флаги

cmake же умеет VC++ использовать?

Так точно

ну тогда надо (очень сильно) устроить соц. опросик

Используешь VC++ для сборки проектов, использующих CMake?

ответил нет, хотя собирал когда-то проект на vs2010, vs2015 и vs2017 из одного и того же cmakelists

проект что-то типа 12 библиотек и экзешник + сборка инсталлера на WiX

но раз вопрос "используешь" - нет, больше не страдаю фигней

ну а у меня на работе всё виндовое, так что юзаю

https://blogs.msdn.microsoft.com/vcblog/2017/08/11/c17-features-and-stl-fixes-in-vs-2017-15-3/

Привет! Я недавно начал изучать C++, а так пишу на шарпе. Мне в голову пришел интересный вопрос, начинается он со следующего: в C++ есть множественное наследование, в шарпе его нет, вместо этого есть множественная реализация интерфейсов. Выходит, как я понял, в C++ есть возможность множественно наследовать классы как абстрактные, так и конкретные. Здесь мне в голову приходит, что множ. наследовать классы от конкретных - вероятно не самая лучшая практика, самое верное приходит - один конкретный, 1 - n абстрактных. Вопрос: как вы поступаете?

Да, всё верно. Имплементацию лучше наследовать только от одного класса.

Причем это можно делать приватно.

А еще можно предпочитать агрегирование наследованию, тоже неплохая практика, говорят.

Привет! Я недавно начал изучать C++, а так пишу на шарпе. Мне в голову пришел интересный вопрос, начинается он со следующего: в C++ есть множественное наследование, в шарпе его нет, вместо этого есть множественная реализация интерфейсов. Выходит, как я понял, в C++ есть возможность множественно наследовать классы как абстрактные, так и конкретные. Здесь мне в голову приходит, что множ. наследовать классы от конкретных - вероятно не самая лучшая практика, самое верное приходит - один конкретный, 1 - n абстрактных. Вопрос: как вы поступаете?

В идеале - обходиться без наследования вообще, кроме случаев когда оно необходимо

А еще можно предпочитать агрегирование наследованию, тоже неплохая практика, говорят.

+

В идеале - обходиться без наследования вообще, кроме случаев когда оно необходимо

Нарушение инкапсуляции?

Нарушение инкапсуляции?

Почему?

В идеале - обходиться без наследования вообще, кроме случаев когда оно необходимо

Я бы сказал так, что наследование интерфейса — плюс\минус ок, наследование имплементации — совсем не ок.

Почему?

Ну я сам еще не понял, но читал у какого то автора, что наследование портит инкапсуляцию

Ну я сам еще не понял, но читал у какого то автора, что наследование портит инкапсуляцию

А, в этом плане. Да, можно сказать и так

Спасибо за ответы, буду думать

Ну я сам еще не понял, но читал у какого то автора, что наследование портит инкапсуляцию

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

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

"а во-вторых дизайн построенный на наследовании реализации нерасширяем" - вот это я заметил

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

Я бы сказал так, что наследование интерфейса — плюс\минус ок, наследование имплементации — совсем не ок.

имплементация интерфейса - это не "плюс/минус ок", лучше вообще ничего не придумали другой вопрос что в крестах всё это сделано криво, но шо ж поделать

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

множественное наследование вопрос спорный

имплементация интерфейса - это не "плюс/минус ок", лучше вообще ничего не придумали другой вопрос что в крестах всё это сделано криво, но шо ж поделать

"другой вопрос что в крестах всё это сделано криво" - вот это тоже пришло в голову :)

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

Вот, кстати, на счёт композиции. Концепция мне известна, но как заменить наследование таким образом? Если можно, какой нибудь простенький пример

Хотя в принцыпе понятно. Это общий функционал между объектами разных классов, в итоге своего рода наследование. То есть, есть надстройка в виде некого объекта, реализующего функционал

ну вот нужен тебе класс который цепляется к базе данных и чё-то там шлёт, при том нужно работать с разными СУБД если делать на наследовании, то ты делаешь обобщённый класс а потом несколько унаследованных от него, каждый из которых работает с какой-то СУБД если на композиции, то логику соединения с базой ты выносишь в отдельный интерфейс, пишешь несколько классов реализующих его а в классе с основной логикой просто делаешь поле содержащее объект класса отвечающего за соединение т.е. очень грубо что-то типа interface IConnection { // ... } class MysqlConnection : IConnection { // ... } class PostgresqlConnection : IConnection { // ... } class Model<C> where C : IConnection { private C connection; // ... }

ну вот нужен тебе класс который цепляется к базе данных и чё-то там шлёт, при том нужно работать с разными СУБД если делать на наследовании, то ты делаешь обобщённый класс а потом несколько унаследованных от него, каждый из которых работает с какой-то СУБД если на композиции, то логику соединения с базой ты выносишь в отдельный интерфейс, пишешь несколько классов реализующих его а в классе с основной логикой просто делаешь поле содержащее объект класса отвечающего за соединение т.е. очень грубо что-то типа interface IConnection { // ... } class MysqlConnection : IConnection { // ... } class PostgresqlConnection : IConnection { // ... } class Model<C> where C : IConnection { private C connection; // ... }

Ага, даже так. Доходчиво. Выходит, далее можно комбинировать функционал таким образом в других классах (не в этом примере, а вообще)

А нет, понял

То есть избавляешься от наследования, с помощью параметризации дженерика

Ага, даже так. Доходчиво. Выходит, далее можно комбинировать функционал таким образом в других классах (не в этом примере, а вообще)

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

То есть избавляешься от наследования, с помощью параметризации дженерика

ну это один из вариантов можно (по крайней мере в C++ и Rust, за C# пояснить не готов, никогда не писал на нём) через динамический диспатчинг это сделать, тогда не будет дженерика, всё становится чуть проще но появляется некоторый оверхед в рантайме

Да с дженериками всё максимально понятно В шарпе почти то же самое public class Model<C> : IConnection { private C connection; // ... }

так я и пытался на шарпе тебе написать) только у тебя же сама модель реализует IConnection, а должно быть чтобы C реализовывало

А, ну да

Тупанул. Ночь сидел, видать поспать пора скоро

> скоро да давно уже)

> скоро да давно уже)

Почему то копаться лучше всего ночью получается. Никто не отвлекает. Инфы намного больше освоить получается,чем за то же дневное время

ну вот нужен тебе класс который цепляется к базе данных и чё-то там шлёт, при том нужно работать с разными СУБД если делать на наследовании, то ты делаешь обобщённый класс а потом несколько унаследованных от него, каждый из которых работает с какой-то СУБД если на композиции, то логику соединения с базой ты выносишь в отдельный интерфейс, пишешь несколько классов реализующих его а в классе с основной логикой просто делаешь поле содержащее объект класса отвечающего за соединение т.е. очень грубо что-то типа interface IConnection { // ... } class MysqlConnection : IConnection { // ... } class PostgresqlConnection : IConnection { // ... } class Model<C> where C : IConnection { private C connection; // ... }

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

Почему то копаться лучше всего ночью получается. Никто не отвлекает. Инфы намного больше освоить получается,чем за то же дневное время

А потом засыпаешь..и...почти ничего не помнишь.

Ну эт образно.

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

в C++ нет ключевого слова interface

Я так некоторые моменты забывал.

в C++ нет ключевого слова interface

+

Код из шарпа походу

А потом засыпаешь..и...почти ничего не помнишь.

Смотря сколько до этого днём поспать

Код из шарпа походу

ну я же сказал что я на шарпе набросал (хоть я его и не знаю, лол)

Сори, не увидел.

interface IConnection { // ... } class MysqlConnection : IConnection { // ... } class PostgresqlConnection : IConnection { // ... } class Model<C> where C : IConnection { private C connection; // ... } Этот? Ну да. Так я его перепутал с cpp, генерики я на нём не писал пока что

(в c++)

C++ generic = template.

В плюсах это принято называть шаблонами. Эт так, к слову.

templates > generics

???

Да, всё верно. Имплементацию лучше наследовать только от одного класса.

С фига ли ? Вообще, ваши рассуждения примерно похожи на следу: "Коллеги, я всё время сплю в женской ночной рубашке, но недавно мне подарили настоящую мужскую пижаму. Я знаю, что ночные рубашки надевают только через голову, но пижаму так не надеть целиком, верхняя часть надевается через голову, а нижняя — нет. Я слышал, что в принципе пижаму можно целиком как-то надеть, но мне приходит в голову, что надевать пижаму через ноги — вероятно, не самая лучшая практика. Как же вы одеваете пижаму ? Знаток пижам: "Да, всё верно, пижаму нужно надевать только через голову"!

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

Эт не вместо.

ERROR: S client not available

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

Там же вроде и то и другое есть

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

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

неудивительно, ведь в шарпе/джаве именно дженерики, там нет шаблонов

как бы генерики и шаблоны —- немного разные вещи

Эт да.

С фига ли ? Вообще, ваши рассуждения примерно похожи на следу: "Коллеги, я всё время сплю в женской ночной рубашке, но недавно мне подарили настоящую мужскую пижаму. Я знаю, что ночные рубашки надевают только через голову, но пижаму так не надеть целиком, верхняя часть надевается через голову, а нижняя — нет. Я слышал, что в принципе пижаму можно целиком как-то надеть, но мне приходит в голову, что надевать пижаму через ноги — вероятно, не самая лучшая практика. Как же вы одеваете пижаму ? Знаток пижам: "Да, всё верно, пижаму нужно надевать только через голову"!

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

как бы генерики и шаблоны —- немного разные вещи

Есть такое, но я бы не сказал, что прям большая разница.

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

Я про джавистов и говорил Но я так понял я что-то упустил и чушь сказал

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

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

С фига ли ? Вообще, ваши рассуждения примерно похожи на следу: "Коллеги, я всё время сплю в женской ночной рубашке, но недавно мне подарили настоящую мужскую пижаму. Я знаю, что ночные рубашки надевают только через голову, но пижаму так не надеть целиком, верхняя часть надевается через голову, а нижняя — нет. Я слышал, что в принципе пижаму можно целиком как-то надеть, но мне приходит в голову, что надевать пижаму через ноги — вероятно, не самая лучшая практика. Как же вы одеваете пижаму ? Знаток пижам: "Да, всё верно, пижаму нужно надевать только через голову"!

можно показать пример, когда множественное наследование имплементации реально полезно?

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

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

generic - runtime template - compile time, что то вроде этого. ну и тележка сверху

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

Я кстати заметил, что это всё чаще проскакивает

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

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

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

Ага, вот я так и понял, что это мелкомягкие постарались

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

(говорю не из-за моего c# бэкграунда)

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

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

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

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

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

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

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

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

Ну это уже косяк. Но сама идея хорошая

Хотя может, конечно, ты пишешь на C++/CLI или C++/CX. Там есть настоящие интерфейсы. Одна проблемка — это не настоящий С++ :)

Погодь, это уже не interface, а какой-то __interface.

Разве что потом это GCC сбилдить

ага, я упустил деталь

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

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

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

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

Много есть всяких кадавров, собранных из C++ и других языков :)