Вы хотите перепривязать указатель к новому объекту, созданному в той же области памяти.
Обычно в использовании std::launder с такой ситуаций нет необходимости. Если там объект попадает в https://eel.is/c++draft/basic.life#8, тогда согласно правилу в https://eel.is/c++draft/basic.life#9, все указатели, ссылки, имена будут указывать на новый объект. Но если там complete const было, тогда уже понадобится использовать std::launder для перепривязки.
Ну или все остальные случаи, когда такое происходит(например там другие типы совсем). То что оно перепривязывается, позволяет не дублировать логику в оператор= для копирования и перемещения, можно взять логику из конструктора:
Нормально общаться, ничего не рассказывая о себе, нельзя.
Ну, тут требуется определить, что понимается под "нормально общяться". Я не считаю, что обязательно рассказывать реальную информацию для обычного общения с людьми. Можно как использовать ложную информацию, как сказать, что всё это личное, просто игнорировать подобные вопросы. Ну и конечно, не рассказывать такое просто так =)
Сбор статистики это не то же самое, что стояние за плечом.
Это тоже самое, что возможность постоять за плечом(и вы при этом даже об этом можете не узнать, что кто-то смотрел) в абсолютно любое время. Поэтому скорее тоже самое, чем нет.
Говоря, что вам всё равно, вы говорите о том, что вам в целом было бы нормально в паноптикуме. Вот мне не было бы.
Чатбот не может дать нормальное общение(он банально не умеет думать), люди же, с общением чисто в чатах, могут. Для этого совсем необязательно деанонимизироваться.
Данные о гражданах гос-ва нужны этому самому государству(собирается информация по всем, даже если конкретно вашу использовать не будут). Как и тем, кто показывает рекламу. Сам факт сбора информации ужасен.
Анонимность должна быть у всех по дефолту, дабы не дать гос-ву собирать информацию, тем кто показывает рекламу анализировать интересы. Это просто право на личную жизнь. Если посмотреть, сколько данных собирают гос-ва и корпорации, то это окажется очень много. Мне неприятно, если за мной 24/7 может кто-то наблюдать, следя за каждым шагом в жизни(ака паноптикум), а вам?
А где RetroShare? Вполне можно его поверх i2p завернуть, будет нормально работать. Да и зачем уж телефон тогда? Дома лучше держать хороший защищённый ноут/комп.
>Шаблоны не отменяют базовые правила языка С++ и не дают возможности в один контейнер разные классы по значению напихать.
Как раз таки дают - std::variant, да std::visit. Ограничения будут ровно такие же, как в случае с ручным енамом, да union, но не нужно делать всё это руками, шаблоны сделают всю работу за нас. Так же, с ним можно делать код, что не будет нарушать OCP, что нарушался при использовании свитча. Получаем: расширяемость, скорость выполнения, уменьшение бойлерплейта, сохраняется возможность использовать шаблонные интерфейсы, чего не было с виртуальными функциями.
1. Тут: operator VALUE() const { auto owner = reinterpret_cast<const OWNER *>(this); // <- Ключевой элемент return (owner->*GETTER)(); } reintepret_cast в данном контексте не меняет то, на какой объект указывает указатель(https://eel.is/c++draft/expr.reinterpret.cast#7). И в связи с этим, указатель продолжает указывтаь на Property. Чтение же объекта из указателя другого типа нелегально(Ссылка на стандарт: https://eel.is/c++draft/basic.lval#11). Исправить ситуацию в данном случае, можно было бы при помощи std::launder(Конечно же с исправлением остальных UB). В коде в целом везде где reinterpret_cast используется, он используется неправильно.
3. auto owner = reinterpret_cast<const OWNER *>(this - OFFSET()); Тут так-же UB. Нет никаких правил в стандарте, которые бы разрешали бы тут pointer arithmetic, а по умолчанию она нелегальна.
По итогу остаётся то, что единственное, что тут можно сделать, это атрибут [[no_unique_address]], реинтерпрет каст + std::launder. Так и это достаточно ограниченно будет, но сделать через if constexpr другое, не такое Zero Overhead поведение для msvc в целом можно.
В общем в целом с такими вещами в плюсах нужно работать весьма осторожно, очень высок риск допустить ошибку, что и произошло в статье. Не стоит игра свечь и лучше взять или классические сеттеры и геттеры, или ссылку на себя передать.
В целом, ещё есть не лучшие моменты в статье. В типе Property, можно было сделать специализацию, дабы не писать руками возвращаемые типы при создании такового.
Буквально не заставляет. Существует такая вещь как cve-rs, там полно вещей, где обходится эта "безопасность" раста. Так и в нём полно вещей, которые не написать без unsafe. Хотя бы вектор.
Вполне себе поддерживает стдлиба модули. import std добавили в 23 стандарте, до этого было другое. Ещё есть и другие библиотеки, которые поддерживают модули. Тот же fmtlib.
>Rust мне в ходе изучения не понравился -- для меня выглядел существенно сложнее C. Я не вижу конкретно в этом хоть каких-либо проблем. Язык должен предоставлять абстракции и возможность писать гибкий, общий код. Для этого, та самая сложность просто необходима. Я лично очень не люблю го или си как раз из-за отсутствия подобных возможностей. А будут люди изучать язык 1 вечер, или же год, вообще разницы не играет в рамках разработки для себя.
С std::variant тут реализация через лаундер не подойдёт. Там она не constexpr будет, а стандарт требует constexpr.
Обычно в использовании std::launder с такой ситуаций нет необходимости. Если там объект попадает в https://eel.is/c++draft/basic.life#8, тогда согласно правилу в https://eel.is/c++draft/basic.life#9, все указатели, ссылки, имена будут указывать на новый объект. Но если там complete const было, тогда уже понадобится использовать std::launder для перепривязки.
Ну или все остальные случаи, когда такое происходит(например там другие типы совсем). То что оно перепривязывается, позволяет не дублировать логику в оператор= для копирования и перемещения, можно взять логику из конструктора:
И использования такого оператора= будет полностью легально, будет работать в constexpr в том числе.
Ещё в статье не хватает более подробного объяснения формальной части этого всего, с ссылками на стандарт.
Поправила, спасибо. Теперь там в requires прокидываются шаблонные аргументы из шаблона главного.
А использование tor всё сильно меняет =)
А что-то говорила тут о социализации? Чат-бот обсуждения даже абстрактных тем предоставить не может, а люди могут. По этой причине люди нужны.
Я не оспаривала тезис, что это "социальный суицид", только "Если вас не интересует реальная жизнь и мир вокруг, то и люди не нужны. ".
Так вот, нужны.
Выше в ветке я написала, что смысл есть всегда(и разницы, что именно делаете нету).
Если вы считаете иначе, то отвечайте лучше туда, а не говорите противоположную точку зрения, при этом никак её не аргументируя.
По моему мнению, этого вполне достаточно для нормального общения.
Ну, тут требуется определить, что понимается под "нормально общяться".
Я не считаю, что обязательно рассказывать реальную информацию для обычного общения с людьми. Можно как использовать ложную информацию, как сказать, что всё это личное, просто игнорировать подобные вопросы. Ну и конечно, не рассказывать такое просто так =)
Это тоже самое, что возможность постоять за плечом(и вы при этом даже об этом можете не узнать, что кто-то смотрел) в абсолютно любое время. Поэтому скорее тоже самое, чем нет.
Говоря, что вам всё равно, вы говорите о том, что вам в целом было бы нормально в паноптикуме.
Вот мне не было бы.
Чатбот не может дать нормальное общение(он банально не умеет думать), люди же, с общением чисто в чатах, могут. Для этого совсем необязательно деанонимизироваться.
Данные о гражданах гос-ва нужны этому самому государству(собирается информация по всем, даже если конкретно вашу использовать не будут). Как и тем, кто показывает рекламу. Сам факт сбора информации ужасен.
Анонимность должна быть у всех по дефолту, дабы не дать гос-ву собирать информацию, тем кто показывает рекламу анализировать интересы. Это просто право на личную жизнь. Если посмотреть, сколько данных собирают гос-ва и корпорации, то это окажется очень много. Мне неприятно, если за мной 24/7 может кто-то наблюдать, следя за каждым шагом в жизни(ака паноптикум), а вам?
А где RetroShare? Вполне можно его поверх i2p завернуть, будет нормально работать. Да и зачем уж телефон тогда? Дома лучше держать хороший защищённый ноут/комп.
>Шаблоны не отменяют базовые правила языка С++ и не дают возможности в один контейнер разные классы по значению напихать.
Как раз таки дают - std::variant, да std::visit. Ограничения будут ровно такие же, как в случае с ручным енамом, да union, но не нужно делать всё это руками, шаблоны сделают всю работу за нас. Так же, с ним можно делать код, что не будет нарушать OCP, что нарушался при использовании свитча. Получаем: расширяемость, скорость выполнения, уменьшение бойлерплейта, сохраняется возможность использовать шаблонные интерфейсы, чего не было с виртуальными функциями.
В конструктор можно принять ссылку на args, а только потом использовать мув на ней.
Данная статья содержит фрагменты кода с UB.
1. Тут:
operator VALUE() const { auto owner = reinterpret_cast<const OWNER *>(this); // <- Ключевой элемент return (owner->*GETTER)(); }reintepret_cast в данном контексте не меняет то, на какой объект указывает указатель(https://eel.is/c++draft/expr.reinterpret.cast#7). И в связи с этим, указатель продолжает указывтаь на Property. Чтение же объекта из указателя другого типа нелегально(Ссылка на стандарт: https://eel.is/c++draft/basic.lval#11). Исправить ситуацию в данном случае, можно было бы при помощи std::launder(Конечно же с исправлением остальных UB). В коде в целом везде где reinterpret_cast используется, он используется неправильно.
2. Вариант с union, а не с атрибутом на [[no_unique_address]], так-же будет с UB. В связи с тем, что https://eel.is/c++draft/basic.life#7.2 требует, чтобы указатель указывал на объект для вызова нестатических методов. https://eel.is/c++draft/class.mem#general-5.sentence-2 Тут же указывается, что любая функция в классе - нестатический метод. https://eel.is/c++draft/basic.life#1 Согласно же этому, в union на момент использования, нет объекта.
3.
auto owner = reinterpret_cast<const OWNER *>(this - OFFSET());Тут так-же UB. Нет никаких правил в стандарте, которые бы разрешали бы тут pointer arithmetic, а по умолчанию она нелегальна.
По итогу остаётся то, что единственное, что тут можно сделать, это атрибут [[no_unique_address]], реинтерпрет каст + std::launder. Так и это достаточно ограниченно будет, но сделать через if constexpr другое, не такое Zero Overhead поведение для msvc в целом можно.
В общем в целом с такими вещами в плюсах нужно работать весьма осторожно, очень высок риск допустить ошибку, что и произошло в статье. Не стоит игра свечь и лучше взять или классические сеттеры и геттеры, или ссылку на себя передать.
В целом, ещё есть не лучшие моменты в статье. В типе Property, можно было сделать специализацию, дабы не писать руками возвращаемые типы при создании такового.
C++ будет на порядки приятнее Java. Языка же C/C++ просто не существует, это совершенно разные языки с разными правилами, разными возможностями.
Буквально не заставляет. Существует такая вещь как cve-rs, там полно вещей, где обходится эта "безопасность" раста. Так и в нём полно вещей, которые не написать без unsafe. Хотя бы вектор.
Вполне себе поддерживает стдлиба модули. import std добавили в 23 стандарте, до этого было другое. Ещё есть и другие библиотеки, которые поддерживают модули. Тот же fmtlib.
В языке C++ есть модули. Были добавлены ещё в прошлом стандарте(формально текущем) - C++20.
(Извиняюсь, отправилось 2 раза)
В языке C++ есть модули. Были добавлены ещё в прошлом стандарте(формально текущем) - C++20.
Хидеры и в C++ писать не надо. И на C++ достаточно приятно писать и высокоуровневый код, умные указатели менеджат что надо.
>Rust мне в ходе изучения не понравился -- для меня выглядел существенно сложнее C.
Я не вижу конкретно в этом хоть каких-либо проблем. Язык должен предоставлять абстракции и возможность писать гибкий, общий код. Для этого, та самая сложность просто необходима. Я лично очень не люблю го или си как раз из-за отсутствия подобных возможностей. А будут люди изучать язык 1 вечер, или же год, вообще разницы не играет в рамках разработки для себя.