AB
Хороший сайт
Size: a a a
2020 June 05
m
Выход view класса из контекста функции требует строк пяти комментариев зачем это вообще надо и проверок, что используются неперемещающие контейнеры, коих в стд примерно 5. В идеале вообще нужно делать отдельный строковый класс и подавлять move конструкторы, потому что возможность синтезировать такие view дописывает невыражаемое в языке условие на деструктор
Я тут немного поэкспериментировал с враперами, но, на сколько я вижу, это почти никак не влияет на результат.
На самом деле, чтобы это работало нужно запретить практически все модифицирующие операции на строке. В том числе деструктор. Потому что даже если использовать враппер
На самом деле, чтобы это работало нужно запретить практически все модифицирующие операции на строке. В том числе деструктор. Потому что даже если использовать враппер
struct { const std::string s; } вектор при ресайзе просто скопирует его и удалит старый инстанс, оставив dangling string_view.CD
Я тут немного поэкспериментировал с враперами, но, на сколько я вижу, это почти никак не влияет на результат.
На самом деле, чтобы это работало нужно запретить практически все модифицирующие операции на строке. В том числе деструктор. Потому что даже если использовать враппер
На самом деле, чтобы это работало нужно запретить практически все модифицирующие операции на строке. В том числе деструктор. Потому что даже если использовать враппер
struct { const std::string s; } вектор при ресайзе просто скопирует его и удалит старый инстанс, оставив dangling string_view.Конструкторы копирования можно использовать для "перемещения", которое логически ошибочно. Оба должны быть удалены
VO
А вот еще вопрос. Допустим у меня в той же шаред памяти есть integer на котором я делаю atomic cas для синхронизации. Мне ведь не нужно его обьявлять как volatile?
Нужно
m
Конструкторы копирования можно использовать для "перемещения", которое логически ошибочно. Оба должны быть удалены
В принципе, да, но без копирования это становится очень узко специализированным классом. В тот же вектор уже не положишь, а у нас был именно такой юз кейс. Здесь можно сказать, что это хорошо, так как спасло бы от ошибки еще на этапе компиляции, но на практике это означает что таким классом никто не будет пользоваться.
CD
В принципе, да, но без копирования это становится очень узко специализированным классом. В тот же вектор уже не положишь, а у нас был именно такой юз кейс. Здесь можно сказать, что это хорошо, так как спасло бы от ошибки еще на этапе компиляции, но на практике это означает что таким классом никто не будет пользоваться.
Размещение цели view в векторе - ошибка, так что невозможность положить в вектор ожидаемое поведение
AY
ясно. Объект не может появиться, если не был вызван конструктор. Получается для случая разделяемой памяти придётся копировать объект в какую-то свою локацию в процессе, который его не создавал в этой разделяемой памяти
Было такое: при обращении к полям uint32_t после приведения даже к POD не выравненной памяти на ARM вылетал SIGBUS. Приходилось делать memcpy в локальную переменную. Подробнее https://stackoverflow.com/questions/19114491/structure-assignment-in-linux-fails-in-arm-but-succeeds-in-x86.
DF
крутой случай
DF
это изза UB?
DF
или конкретно изза арма?
AY
/proc/cpu/alignement
AY
была бы большая просадка по производительности насколько я понимаю.
AT
на AVR такое, помнится, было
AB
Dollar Føølish
или конкретно изза арма?
В арме раньше был невозможен невыровненный доступ
AY
В арме раньше был невозможен невыровненный доступ
О
Потому что тебе в другой чат, тебе в суп.
@supapro
@supapro
Не успел пройти анти-бот проверку, теперь не пускает (
DF
В арме раньше был невозможен невыровненный доступ
да, собственно поэтому и вопрос :) ключевое здесь UB или старый арм? :)
AB
Невыровненный доступ был и есть уб
SK
Dollar Føølish
да, собственно поэтому и вопрос :) ключевое здесь UB или старый арм? :)
и то и другое. в новых армах даже в милипизерных v7-m кортекс-м3 невыровненный доступ есть!