AB
Для тех случаев, когда нужно иметь доступ к адресу 0
Size: a a a
2020 June 22
AT
по-хорошему проверять указатель надо сравнением с nullptr, а не конверсией в bool
AB
по-хорошему проверять указатель надо сравнением с nullptr, а не конверсией в bool
По причине?
AT
по причине того, что в общем случае любой адрес может быть валидным
AP
по причине того, что в общем случае любой адрес может быть валидным
всё верно, поэтому (в теории) nullptr != 0 на платформах, где можно размещать объекты по нулевому адресу
AB
Конверсия указателя в бул определена как отрицание сравнения с нулевым указателем
S
по причине того, что в общем случае любой адрес может быть валидным
Если любой валидный - то негде хранить признак nullptr)
AT
Могу привести аналогию с каким-нибудь
int? из мира .NET-а или nullable-поля в базах данных. Неинициализированный указатель как раз таким нулевым значением и является.S
Могу привести аналогию с каким-нибудь
int? из мира .NET-а или nullable-поля в базах данных. Неинициализированный указатель как раз таким нулевым значением и является.в nullable в C# дополнительные биты появляются
а в C++ этого нет
а в C++ этого нет
std::option<T*> Тогда ужDB
Могу привести аналогию с каким-нибудь
int? из мира .NET-а или nullable-поля в базах данных. Неинициализированный указатель как раз таким нулевым значением и является.В частности - это сахар вокруг булевого флага, который определяет, что в типе не задано значение
AT
В частности - это сахар вокруг булевого флага, который определяет, что в типе не задано значение
Не совсем так. Там много подкапотной магии в JIT-е. Например boxing с Nullable<T> работает совсем не так как с другими структурами.
AT
в nullable в C# дополнительные биты появляются
а в C++ этого нет
а в C++ этого нет
std::option<T*> Тогда ужДа, примерно так
A
да, я бы предпочёл видеть ошибку компиляции
+, надо в язык добавить consteval throw, чтобы он в ошибку компиляции переходил (и consteval catch, чтобы можно было обрабатывать)
AB
+, надо в язык добавить consteval throw, чтобы он в ошибку компиляции переходил (и consteval catch, чтобы можно было обрабатывать)
s/eval/expr/g, чтобы как с ифом
m
+, надо в язык добавить consteval throw, чтобы он в ошибку компиляции переходил (и consteval catch, чтобы можно было обрабатывать)
Мне кажется или вместе с constexpr new добавляли и constexpr обработку исключений?
AB
Они могут быть в constexpr. Но пока функция не вызвана в constexpr контексте нет гарантии, что исключение будет в constexpr
p
For the request "1002":
P1002R0: Try-catch blocks in constexpr functions from Louis Dionne
https://wg21.link/p1002r0
P1002R1: Try-catch blocks in constexpr functions from Louis Dionne
https://wg21.link/p1002r1
P1002R0: Try-catch blocks in constexpr functions from Louis Dionne
https://wg21.link/p1002r0
P1002R1: Try-catch blocks in constexpr functions from Louis Dionne
https://wg21.link/p1002r1
A
Вопрос по boost::beast (и asio).
Возьмём пример асинхронного http сервера из документации. Является ли вызов async_write потокобезопасным? Например, в on_read я не сразу вызываю async_write, а создаю отдельный поток, который ждёт 3 секунды и после вызывает async_write. Нужно ли что-то блокировать для этого? Или проверять валидность каких-нибудь объектов?
Судя по доке - всё должно быть ок, так как никаких других асинхронных операций на данной сессии у меня после on_read быть не может (повторное чтение я не запускал, запись также ещё не началась), а значит и async_write можно звать без синхронизации.
Все объекты в shared_ptr + enable_shared_from_this, так что ссылки не протухнут
Возьмём пример асинхронного http сервера из документации. Является ли вызов async_write потокобезопасным? Например, в on_read я не сразу вызываю async_write, а создаю отдельный поток, который ждёт 3 секунды и после вызывает async_write. Нужно ли что-то блокировать для этого? Или проверять валидность каких-нибудь объектов?
Судя по доке - всё должно быть ок, так как никаких других асинхронных операций на данной сессии у меня после on_read быть не может (повторное чтение я не запускал, запись также ещё не началась), а значит и async_write можно звать без синхронизации.
Все объекты в shared_ptr + enable_shared_from_this, так что ссылки не протухнут
должно быть норм, пока ты не шаришь стейты..