Вроде бы простой банальный доклад чувака из Adobe, а с другой стороны не совсем. Основные посылы:
— С++ отлично поддерживает value types, поэтому используйте эту возможность по максимуму, где это возможно и не будете иметь каскад описанных в докладе проблем.
— Reference types — тоже самое, что глобальные переменные, поэтому избегайте эту семантику как только можете.
Value Semantics: Safety, Independence, Projection, & Future of Programming — Dave Abrahams CppCon 22
А интересным он показался мне потому, что я, неосознанно, сам начал скатываться к тем же методам что используются в докладе, но не мог четко обосновать самому себе. Особенно актуально в свете массовой многопоточки и параллельности.
Интересно мнение коллег, кто что думает на эту тему?
σ>>Полистал слайды, ничего специфичного для более новых плюсов. Да и вообще маловато материала.
SP>там же приводится пример с методом sort когда вектор принимается по значению. В доисторических плюсах получили бы минимум одно копирование вектора.
Доисторических — это каких? Более новых — это чем C++11.
Ну да, идёя хорошая. Применять, к сожалению, не приходилось.
Что же до контента, то всё что там есть в презентациях (про Value Semantics, про Type Erasure) было обcосано в видео Шон Пэрена 2012-2017 годов, а текстом наверняка ещё раньше, скорее всего даже в 90-х.
80+% докладов на CppCon повторяется из года в год.
Здравствуйте, Videoman, Вы писали:
V>Вроде бы простой банальный доклад чувака из Adobe, а с другой стороны не совсем. Основные посылы:
V>[cut=Value Semantics: Safety, Independence, Projection, & Future of Programming — Dave Abrahams CppCon 22]
Abrahams — кто угодно, но только не банальный чувак. Это он придумал метапрограммирование в С++ (с Dimov).
Здравствуйте, Vamp, Вы писали:
V>>Вроде бы простой банальный доклад чувака из Adobe, а с другой стороны не совсем. Основные посылы:
V>Abrahams — кто угодно, но только не банальный чувак. Это он придумал метапрограммирование в С++ (с Dimov).
чего это вдруг?
какие библиотеки он (Abrahams) разработал?
Здравствуйте, Vamp, Вы писали:
V>Abrahams — кто угодно, но только не банальный чувак. Это он придумал метапрограммирование в С++ (с Dimov).
Да я и не утверждал, что Абрахамс банальный. Банальный — понятие относительное. Доклад становится банальным, когда ты сам до всех этих выводов и практик дошел практически, но без обоснований, а потом смотришь доклад и думаешь: за мной следят!
Здравствуйте, night beast, Вы писали:
NB>буст это коллекция библиотек разных авторов. NB>какую конкретно в бусте сделал лично он?
Он один из основателей буста в принципе и автор более чем 3-х тысяч коммитов. Там дохера модулей, в которых он указан автором. Можно сказать, что также играл роль архитектора проекта в целом.
N>>Exception safety в stl. NB>про Exception safety я читал не у Абрахамса. он точно первый начал про это говорить?
Я не сказал, что он первым начал об этом говорит, он принёс это в boost и STL. Возможно, что и первый в таком свете.
NB>ну и к метапрограммированию это не сильно относится.
Он в принципе один из первых это начал продвигать в семинарах и статьях, потом книгу написал.
Здравствуйте, Nuzhny, Вы писали:
NB>>какую конкретно в бусте сделал лично он?
N>Он один из основателей буста в принципе и автор более чем 3-х тысяч коммитов. Там дохера модулей, в которых он указан автором.
здесь можно посмотреть, каких именно.
чего-то выдающегося не увидел
N>Можно сказать, что также играл роль архитектора проекта в целом.
то есть это его надо благодарить за то что коллекцию библиотек превратили в хренов монолит, вытащить что-то из которого тот еще геморрой?
что такого интересного в плане архитектуры у буста есть?
свои системы сборки, документирования, тестирования. то есть по сути свой набор велосипедов, которыми никто кроме них самих не нужен (за исключением теста, да и тот где буст не используют, вряд-ли применят)
отличное архитектурное решение.
N>>>Exception safety в stl. NB>>про Exception safety я читал не у Абрахамса. он точно первый начал про это говорить?
N>Я не сказал, что он первым начал об этом говорит, он принёс это в boost и STL. Возможно, что и первый в таком свете.
как то мелковато для "основателя метапрограммирования"
NB>>ну и к метапрограммированию это не сильно относится. N>Он в принципе один из первых это начал продвигать в семинарах и статьях, потом книгу написал.
вроде бы, книгу написал Алексей Гуртовой (автор mpl), а Абрахамс там соавтором. но это не точно.
Здравствуйте, night beast, Вы писали:
NB>здесь можно посмотреть, каких именно. NB>чего-то выдающегося не увидел
9 библиотек, причём от уже 13 лет им не занимается. Неплохо.
NB>то есть это его надо благодарить за то что коллекцию библиотек превратили в хренов монолит, вытащить что-то из которого тот еще геморрой?
В первую очередь, он создал коллекцию библиотек, раньше её не было. Создал свою систему сборки, документирования и тестирования. Превратил всё это чуть ли не во вторую стандартную библиотеку, плацдарм для исследования идей и новых библиотек. Роль буста в С++ сложно переоценить.
NB>как то мелковато для "основателя метапрограммирования"
?!!
NB>вроде бы, книгу написал Алексей Гуртовой (автор mpl), а Абрахамс там соавтором. но это не точно.
Обычно, кто первый указан в списке соавторов, тот больше и написал.
Здравствуйте, Nuzhny, Вы писали:
NB>>здесь можно посмотреть, каких именно. NB>>чего-то выдающегося не увидел
N>9 библиотек, причём от уже 13 лет им не занимается. Неплохо.
посмотри, в скольких из них он является единственным автором.
NB>>то есть это его надо благодарить за то что коллекцию библиотек превратили в хренов монолит, вытащить что-то из которого тот еще геморрой?
N>В первую очередь, он создал коллекцию библиотек, раньше её не было. Создал свою систему сборки, документирования и тестирования. Превратил всё это чуть ли не во вторую стандартную библиотеку, плацдарм для исследования идей и новых библиотек. Роль буста в С++ сложно переоценить.
он мог бы стать трамплином для развития, но стал лишь одной из многих библиотек.
делай они все по уму, у нас бы возможно в 2023 г. были нормальные пакетный менеджер и система сборки.
так что да, роль буста в текущем состоянии плюсов сложно переоценить.
NB>>вроде бы, книгу написал Алексей Гуртовой (автор mpl), а Абрахамс там соавтором. но это не точно. N>Обычно, кто первый указан в списке соавторов, тот больше и написал.
Здравствуйте, Videoman, Вы писали:
V>Интересно мнение коллег, кто что думает на эту тему?
Моё мнение: с этим докладом всё неверно, начиная от ошибочные архитектурно неверные решения исправляются неверными методами.
Пример на 7:07 class invariant
в классе две коллекции вектора xs и ys.
Проблема: нарушение инварианта при добавлении нового элемента в xs.
Далее автор утверждает, что это не проблема если данные приватны и начинает рассуждать о графе ссылок...
То, что эти данные приватные ничего не меняет, если вектора два, то должен существовать код обеспечивающий их инвариантность...
Фактически это архитектурно неверное решение, так как нам надо заниматься согласованием двух независимых объектов xs и ys. "заниматься согласованием" — это означает дополнительную работу, дополнительный код, который занимается согласованием, для обеспечения инвариантности. Но смотрите: если объединить x и y в одну структуру, то у нас останется один вектор xy для которого инвариантность соблюдается автоматически! И никакого дополнительного кода, никаких проверок не надо.
Здравствуйте, B0FEE664, Вы писали:
BFE>Пример на 7:07 class invariant
BFE>То, что эти данные приватные ничего не меняет, если вектора два, то должен существовать код обеспечивающий их инвариантность... BFE>Фактически это архитектурно неверное решение, так как нам надо заниматься согласованием двух независимых объектов xs и ys.
Не понял с чем ты не согласен. Два вектора это данность, это просто пример двух классов членов другого класса, между которыми нужно поддерживать строго определённый набор состояний. Он просто таким образом иллюстрирует зачем нужен класс и что такое поддержка инварианта. Представь что ты не можешь их объединить, что это два независимых класса, какие-нибудь: gl::vector и dx::vector.
Если инвариант не нужен, то и класс не нужен. Достаточно структуры.
BFE>И далее всё так же...
Дальше всё совсем не об этом.
Здравствуйте, Videoman, Вы писали:
V>Не понял с чем ты не согласен. Два вектора это данность, это просто пример двух классов членов другого класса, между которыми нужно поддерживать строго определённый набор состояний. Он просто таким образом иллюстрирует зачем нужен класс и что такое поддержка инварианта. Представь что ты не можешь их объединить, что это два независимых класса, какие-нибудь: gl::vector и dx::vector.
Ну, если у нас такая ситуация, то у нас проблема: ошибка проектирования. Но каким образом это относится к Value Semantics ?
V>Если инвариант не нужен, то и класс не нужен. Достаточно структуры. BFE>>И далее всё так же... V>Дальше всё совсем не об этом.
Не об этом, но в таком же стиле. Какие-то не связанные друг с другом задачи и не относящиеся к ним решения.
Там по делу наверное только про сортировку, но:
— то, что при наличии возможности перемещать объекты, объекты следует перемещать, а не передавать на них ссылки говорилось сразу после введения С++11.
— что будет с вектором, когда (на 35:44) при сортировке будет брошено исключение? Потеряем все данные?
К чему там всё остальное вообще не понятно. Если память не ресурс, то на каждое изменение копируем значение — это теория программирования первого курса университета.
Здравствуйте, B0FEE664, Вы писали:
BFE>Ну, если у нас такая ситуация, то у нас проблема: ошибка проектирования. Но каким образом это относится к Value Semantics ?
Да что ты привязался к конкретике. Он просто объясняет что такое инвариант, зачем нужен класс и что по его мнению инварианты легко нарушить с reference semantics.
BFE>Там по делу наверное только про сортировку, но: BFE>- что будет с вектором, когда (на 35:44) при сортировке будет брошено исключение? Потеряем все данные?
Не знаю что ты увидел на 35:44, не понятно, приведи пример
BFE>К чему там всё остальное вообще не понятно. Если память не ресурс, то на каждое изменение копируем значение — это теория программирования первого курса университета.
Тут фиг поспоришь. Функциональное программирование наше всё. Жалко что на практике память тоже нужна.
Здравствуйте, night beast, Вы писали:
NB>то есть это его надо благодарить за то что коллекцию библиотек превратили в хренов монолит, вытащить что-то из которого тот еще геморрой?
А я так и не понял, зачем оттуда что-то вытаскивать. Место на диске экономить? Или какие-то религиозные заморочки?
Что не используешь — то не мешает. Зато установить можно разом, а не возиться из-за каждой новой понадобившейся фичи.
Есть, правда, еще лицензионные политики, но с ними вопросы не к бусту, а к тем, кто эти политики навязывает — у буста очень удобная лицензия для любого рода проектов.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, ути-пути, Вы писали:
NB>>то есть это его надо благодарить за то что коллекцию библиотек превратили в хренов монолит, вытащить что-то из которого тот еще геморрой?
УП>А я так и не понял, зачем оттуда что-то вытаскивать. Место на диске экономить? Или какие-то религиозные заморочки? УП>Что не используешь — то не мешает. Зато установить можно разом, а не возиться из-за каждой новой понадобившейся фичи.
затем что мне не нужно в проекте то, что я не использую
если кто-то тащит к себе всякое г-но со своими зависимостями, только потому что это модно, то это его личные трудности.
Я долго откладывал написание соображений на эту тему. В начале думал создать отдельный пост.
Я написал версию двух вспомогательных шаблонов cref<T> и in<T> , служащих для передачи параметров в функцию.
Как на ваш взгляд можно сделать лучше?
in<T> мувает полученный параметр во внутреннее состояние с предоставлением доступа на запись/чтение.
Его нестатический метод move() нужен к примеру чтобы вернуть значение из функции.
Про inout<> и ref<> я напишу отдельно (скорее всего ответом на исходную тему).
std::array мувать смысла видимо нет, вот для него и ref<> сойдёт.
Зачем вам нужен make_cref()? Напомню, что такой cref предназначен лишь для входных параметров функции.
А вы его возвращаете из return и используете не по назначению.
Это просто чтобы не писать const type & — а для наглядности. Но какой в этом тогда смысл?
Его определение можно по желанию переписать для trivial типов через std::conditional, чтобы они по const копии передавались, а не по ссылке.
Например зачем char передавать по конст ссылке?
S>Зачем вам нужен make_cref()? Напомню, что такой cref предназначен лишь для входных параметров функции.
1. Из чего следует, что cref нельзя использовать так, как показал я?
2. Что случится плогого, если доработать его таким образом, чтоб он гарантированно обеспечивал константную ссылку и соответствовал своему названию?
S>Это просто чтобы не писать const type & — а для наглядности. Но какой в этом тогда смысл? S>Его определение можно по желанию переписать для trivial типов через std::conditional, чтобы они по const копии передавались, а не по ссылке. S>Например зачем char передавать по конст ссылке?
Ну то есть, он нужен только для того, чтоб мешать программистам объявлять типы формальных параметров функций так как им хочется. Офигенно полезная утилита
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, Sm0ke, Вы писали:
S>Зачем вам нужен make_cref()? Напомню, что такой cref предназначен лишь для входных параметров функции. S>А вы его возвращаете из return и используете не по назначению.
Ну, хорошо, можно и без make_cref, и без return. В таком примере все "по назначению"?
Здравствуйте, Sm0ke, Вы писали:
S>Его определение можно по желанию переписать для trivial типов через std::conditional, чтобы они по const копии передавались, а не по ссылке.
После чего сразу же поломается возможность автоматического выведения типов при использовании этого cref для задания типов формальных параметров шаблонов функций.
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, rg45, Вы писали:
R>Здравствуйте, Sm0ke, Вы писали:
S>>Зачем вам нужен make_cref()? Напомню, что такой cref предназначен лишь для входных параметров функции. S>>А вы его возвращаете из return и используете не по назначению.
R>Ну, хорошо, можно и без make_cref, и без return. В таком примере все "по назначению"?
R>http://coliru.stacked-crooked.com/a/c4d021b1f60b8384
R>
Здравствуйте, Videoman, Вы писали:
V>- С++ отлично поддерживает value types, поэтому используйте эту возможность по максимуму, где это возможно и не будете иметь каскад описанных в докладе проблем.
А что, многие имели каскад описываемых проблем? Вот всю жизнь так делали и вот тебе на, оказывается проблемы на ровном месте. V>- Reference types — тоже самое, что глобальные переменные, поэтому избегайте эту семантику как только можете.
Скоуп всё же меньше, не надо драматизировать и нагнетать. В рамках этого скоупа можно легко понять кто и что меняет. V>А интересным он показался мне потому, что я, неосознанно, сам начал скатываться к тем же методам что используются в докладе, но не мог четко обосновать самому себе. Особенно актуально в свете массовой многопоточки и параллельности.
Это будет работать если обеспечить атомарность конструктора копирования или перемещения, тогда можно будет запускать несколько функций в разных потоках не беспокоясь о гонках, т.к. все они будут работать со своей копией данных.
Ещё коллега B0FEE664 задал корректный вопрос про исключение при move. V>Интересно мнение коллег, кто что думает на эту тему?
Насмотрелись на иммутабельность в функциональных языках и тащат теперь везде. Я думаю проблема связана больше с конструкциями async/await в итоге, чем с тем что он приводил как "проблему".
Здравствуйте, B0FEE664, Вы писали:
BFE>То, что эти данные приватные ничего не меняет, если вектора два, то должен существовать код обеспечивающий их инвариантность... BFE>Фактически это архитектурно неверное решение, так как нам надо заниматься согласованием двух независимых объектов xs и ys. "заниматься согласованием" — это означает дополнительную работу, дополнительный код, который занимается согласованием, для обеспечения инвариантности. Но смотрите: если объединить x и y в одну структуру, то у нас останется один вектор xy для которого инвариантность соблюдается автоматически! И никакого дополнительного кода, никаких проверок не надо.
BFE>И далее всё так же...
Т.е. поработали над 2мя типами структур, сделали 1у и теперь всё норм? Можно лишь 1 вектор. Звучит не плохо. Т.е. он же, к примеру, работал с тем что ему дали. И сказал почему это плохо. Может, мы можем провести аналогии и к нашему коду и сделать подобное улучшение, что он показал.