тогда бы это было во всех режимах

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

не, в примере память вообще не используется, там всё помещается в регистры.

if (NOT DEFINED CMAKE_CXX_STANDARD) set(CMAKE_CXX_STANDARD 11) endif ()

а перед этим option(CMAKE_CXX_STANDARD ...) тогда

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

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

Привет! Я недавно начал изучать 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; // ... }

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

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

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

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

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