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

Шоб можно было делать маски

Дескать несколько опций задавать, setFlags(C1 | C2)

Прошу прощения! Не для констант, а для флагов.

Дескать несколько опций задавать, setFlags(C1 | C2)

Про маски не понял. А почему нельзя с другими степенями?

Про маски не понял. А почему нельзя с другими степенями?

ты знаешь, как выглядит целое число в двоичном виде?

Я вообще себе слабо представляю биты и все такое..

ну так время представить

А может просто дать ответ на вопрос и я уже потом сам буду представлять?

Меня только интересует конкретно, это только степень двойки при сложении не может повторить результат?

ты знаешь, как выглядит целое число в двоичном виде?

А вы знаете? Можете на мойпоследний вопрос ответить?

Меня только интересует конкретно, это только степень двойки при сложении не может повторить результат?

@supapro

Меня только интересует конкретно, это только степень двойки при сложении не может повторить результат?

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

Дальнейшее обсуждение сего вопроса здесь будет вытираться

У нас есть чат для таких вопросов - я тебя туда перенаправил, так как считаю, что тот чат более уместен для таких вопросов

Copy elision в лямбдах пока не предвидится? Надо писать [self=std::move(shared_from_this())] ( auto &&param) { self->method(param); }; вместо [self=shared_from_this()] ( auto &&param) { self->method(param); }; Чтобы не делать атомарного инкремента/декремента?

Нельзя в лямбду захватывать shared_ptr - память же потечет.

Куда потечет?

Нельзя в лямбду захватывать shared_ptr - память же потечет.

Как функциональный объект пройдёт деструкцию - счётчик ссылок уменьшается. Всё норм

shared_from_this создает новый shared_ptr, увеличивая счётчик ссылок, потом возвращает новый shared_ptr, лямбда из возвращённого rvalue захватывает перемещением shared_ptr Все нормально

Это то же самое что объект template <class SelfType> struct Lambda { std::shared_ptr<SelfType> self; template<class T> void operator()(T &&param) { self->method(param); } }; Не?

Если бы у лямбды ещё mutable было

Как функциональный объект пройдёт деструкцию - счётчик ссылок уменьшается. Всё норм

Это очень хрупкий момент. Очень легко его проморгать и наступить на граблю. Rule of thumb - не делать так никогда

Не вижу там ничего хрупкого

А зря. Очень легко сделать циклическую зависимость. Не сегодня, дак через месяц при рефакторинге/редизайне. Причем зависимость может быть очень нетривиальной - через цепочку 3-5 объектов. После нескольких подобных инцидентов мы ввели жесткое правило - в лямбду только weak_ptr

А зря. Очень легко сделать циклическую зависимость. Не сегодня, дак через месяц при рефакторинге/редизайне. Причем зависимость может быть очень нетривиальной - через цепочку 3-5 объектов. После нескольких подобных инцидентов мы ввели жесткое правило - в лямбду только weak_ptr

В этом согласен

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

Нельзя в лямбду захватывать shared_ptr - память же потечет.

Можно захватывать, конечно

А зря. Очень легко сделать циклическую зависимость. Не сегодня, дак через месяц при рефакторинге/редизайне. Причем зависимость может быть очень нетривиальной - через цепочку 3-5 объектов. После нескольких подобных инцидентов мы ввели жесткое правило - в лямбду только weak_ptr

Вопрос лишь в том, что вы перепутали причину со следствием. У вас shared_ptr не выражающий владения, вот и привет обертки на maybe

Когда условное SomeWindow выставляет обработчик своему компоненту, там нет ни shared, ни weak

Привет, плюсачик

А dynamic_poiner_cast работает только при прямом наследовании?

struct А : B, C из B - C получить нельзя же?

Если правильно помню, правила те же, что с dynamic_cast должны быть

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

struct А : B, C из B - C получить нельзя же?

Можно, так работать будет: #include <iostream> #include <memory> struct B { virtual ~B() {} }; struct C { virtual ~C() {} }; struct A : B, C {}; void test(std::shared_ptr<B> ptr) { if (std::dynamic_pointer_cast<C>(ptr)) std::cout << "yes\n"; else std::cout << "no\n"; } int main() { test(std::make_shared<A>()); }

Я больше склоняюсь к ошибке в дизайне

+++, множественное наследование это почти всегда ошибка в дизайне

Нет, множественное - это норм

А вот у меня, видимо, не нужнотисполтзовать интерфейс в этом месте

Нет, множественное - это норм

Пруф или не было

Люди поколеченные джавой - спокойнее

норм наброс

Next time somebody tells you that you should never use multiple inheritance, look them straight in the eye and say, “One size does not fit all.”

https://isocpp.org/wiki/faq/multiple-inheritance#mi-not-evil

Люди поколеченные джавой - спокойнее

Это не аргумент. И я программирую только на C++ и ни на чем, кроме C++

Пруф или не было

Интерфейсы?

Любая технология ок, если можешь ее использовать правильно

CRTP

Любая технология ок, если можешь ее использовать правильно

Так я и задаю вопрос хотя бы одном случае, когда её использование правильно (и не является костылем^W метафорой языка)

Под последним я понимаю случаи вроде enable_shared_from_this и binary_function, давайте их не рассматривать

Синтаксис C++ содержит метки и goto, но что-то желание их использовать в C++ особо не возникает

При чем тут твое желание? Нет ничего плохого в готу, если ты их грамотно используешь

Я тут мимо проходил, очень боюсь влезать в холивары и тратить на них время, но всё же выскажу своё мнение. Множественное наследование - замена композиции, пока не завезли перегрузку operator.. Просто чтобы было меньше кода

При чем тут твое желание? Нет ничего плохого в готу, если ты их грамотно используешь

Вы используете метки и goto

Я тут мимо проходил, очень боюсь влезать в холивары и тратить на них время, но всё же выскажу своё мнение. Множественное наследование - замена композиции, пока не завезли перегрузку operator.. Просто чтобы было меньше кода

Ну я как минимум привел два костыля, когда множественное наследование подпирает другие дефекты

Так чем реализация многих интерфейсов или составление нового интерфейса из базовых не является корректным использованием?

Нет, но не потому что не хочу, а потому что нет необходимости. А вот в наследовании есть необходимость и его использую. И в синглтонах есть и их использую и клал я болт на всех этих академичечких программистов, которые рассказывают мне, как писать проекты

Нет, но не потому что не хочу, а потому что нет необходимости. А вот в наследовании есть необходимость и его использую. И в синглтонах есть и их использую и клал я болт на всех этих академичечких программистов, которые рассказывают мне, как писать проекты

Вы все еще не привели пример

Так чем реализация многих интерфейсов или составление нового интерфейса из базовых не является корректным использованием?

Это не пример, это какое-то абстрактное рассуждение

Ну я как минимум привел два костыля, когда множественное наследование подпирает другие дефекты

Ооп описывает объекты. Сложные объекты могут иметь свойства разных объектов - множественное наследование сюда отлично вписывается

иметь свойства == имплементить интерфейсы

Использование goto замечательно позволяет переходить к обработчику ошибок и унифицированному возврату (см. язык С)

Я тут мимо проходил, очень боюсь влезать в холивары и тратить на них время, но всё же выскажу своё мнение. Множественное наследование - замена композиции, пока не завезли перегрузку operator.. Просто чтобы было меньше кода

я видать что-то пропустил, а когда будет operator . и для чего он нужен?

иметь свойства == имплементить интерфейсы

И чем это не множественное наследование?

Использование goto замечательно позволяет переходить к обработчику ошибок и унифицированному возврату (см. язык С)

Господа, требование примера возникает не просто так. Вы пользуетесь goto по этой причине? Думаю, нет

Господа, требование примера возникает не просто так. Вы пользуетесь goto по этой причине? Думаю, нет

goto для выхода из двойного цикла - спокойно заюзаю, если припрёт

я видать что-то пропустил, а когда будет operator . и для чего он нужен?

да были тут пропозалы от умных людей, чтобы можно было делать удобные прокси объекты, всякие там property средствами языка реализовывать и так далее. аналог перегрузки operator->, только точку. пишешь так foo.bar, а тебе какая-нибудь другая штука возвращается на самом деле

goto для выхода из двойного цикла - спокойно заюзаю, если припрёт

а пробовали вынести функцию?

да были тут пропозалы от умных людей, чтобы можно было делать удобные прокси объекты, всякие там property средствами языка реализовывать и так далее. аналог перегрузки operator->, только точку. пишешь так foo.bar, а тебе какая-нибудь другая штука возвращается на самом деле

проперти есть в msvc диалекте :)))

я видать что-то пропустил, а когда будет operator . и для чего он нужен?

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4173.pdf

И чем это не множественное наследование?

есть существенная разница между наследованием интерфейса и имплементации

проперти есть в msvc диалекте :)))

знаем, юзали, очень приятная вещь. хотя это ещё один повод для холивара

чем-то плохим иногда считают второе

знаем, юзали, очень приятная вещь. хотя это ещё один повод для холивара

аналогично - юзал, получаются очень симпотишные конструкции иногда

При чем тут твое желание? Нет ничего плохого в готу, если ты их грамотно используешь

Оператор goto в C++ - это антипаттерн. В хорошем коде этого быть не должно.

аналогично - юзал, получаются очень симпотишные конструкции иногда

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

Оператор goto в C++ - это антипаттерн. В хорошем коде этого быть не должно.

Угу. Я на этом примере пытаюсь объяснить, что в абстрактных рассуждениях выявлять ошибки очень сложно

есть существенная разница между наследованием интерфейса и имплементации

Так никто не говорил про наследование имплементаций. Простотобсужжается множественное наследование

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

хм... а там требуется не что-то типа адреса функции по сути?!

Угу. Я на этом примере пытаюсь объяснить, что в абстрактных рассуждениях выявлять ошибки очень сложно

Разумеется. Отладка кода с кучей goto (например ядро Linux) - это всегда боль.

Оператор goto в C++ - это антипаттерн. В хорошем коде этого быть не должно.

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

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

В хорошей компании код на C++ с goto не пройдёт review и тебя заставят его переписать.

Разумеется. Отладка кода с кучей goto (например ядро Linux) - это всегда боль.

Угу. Видимо, логика типа ФП внезапно улучшает читаемость кода (если не доводить до абсурда)

Между тем, "использование goto замечательно позволяет переходить к обработчику ошибок и унифицированному возврату (см. язык С)"

Абстрактное рассуждение, с которым очень сложно работать

Угу. Видимо, логика типа ФП внезапно улучшает читаемость кода (если не доводить до абсурда)

Фп очень положительно влияет на код, если пишешь какие-то матано вычисления

хм... а там требуется не что-то типа адреса функции по сути?!

неа: https://godbolt.org/z/_7VSB9

В хорошей компании код на C++ с goto не пройдёт review и тебя заставят его переписать.

Linux не в счёт?

Linux не в счёт?

Linux - это голый Си. Речь о C++. В Си использование goto как раз уместно.

неа: https://godbolt.org/z/_7VSB9

и static_cast не встает, грустно

Не понимаю спора. Каждому инструменту – своё применение. И у goto оно тоже имеется, пусть и во всё меньшем количестве. Но идеалогическая ненависть безотносительно к конкретному случаю – плохо

Ну вот есть break, return и throw как варианты перехода "к нужному месту". Какие сценарии goto не покрывает?