Телеграмм чат группы fludpac страница 16100

2020 February 26

АК

move_if_notrow and etc

Это спасает только от проблем с муваньем в новое хранилище :(
Обрабатывать все остальные потенциально бросающие места нужно ручками

источник

10:14пожаловаться #1

N

Neargye in cxx.Дискуссионная

Александр Караев

Это спасает только от проблем с муваньем в новое хранилище :(
Обрабатывать все остальные потенциально бросающие места нужно ручками

Ну для начало уже неплохо

источник

10:14пожаловаться #2

АВ

Александр Вольнов in cxx.Дискуссионная

Александр Караев

Например, vector::push_back:
If an exception is thrown (which can be due to Allocator::allocate() or element copy/move constructor/assignment), this function has no effect (strong exception guarantee).

Я так понимаю, они ради неё жертвуют производительностью и вместо перемещения используют копирование в случае не noexcept move конструктора. Может так и сделаю.

источник

10:24пожаловаться #3

АК

Александр Караев in cxx.Дискуссионная

Александр Вольнов

Я так понимаю, они ради неё жертвуют производительностью и вместо перемещения используют копирование в случае не noexcept move конструктора. Может так и сделаю.

Я выше написал - проблему бросающего исключения конструктора копирования/аллокатора/operator= это не решает

источник

10:26пожаловаться #4

АВ

Александр Вольнов in cxx.Дискуссионная

Александр Караев

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

Сначала всё делалось для себя под свои проекты, где у меня исключения вообще не используются. Но потом я всё-таки задумался о том, что надо сделал как надо, чтобы мою либу юзали и даже у себя таску отметил об exception safety. Но пока ещё не успел её сделать. Если в move конструкторе вылетит исключение, скорее всего будет UB и креш, даже базовой гарантии сейчас нет.

источник

10:27пожаловаться #5

АК

Александр Караев in cxx.Дискуссионная

Александр Вольнов

Сначала всё делалось для себя под свои проекты, где у меня исключения вообще не используются. Но потом я всё-таки задумался о том, что надо сделал как надо, чтобы мою либу юзали и даже у себя таску отметил об exception safety. Но пока ещё не успел её сделать. Если в move конструкторе вылетит исключение, скорее всего будет UB и креш, даже базовой гарантии сейчас нет.

О том и речь - более специфические контейнеры могут быть быстрее менее специфических, но дают меньше гарантий. Если уж позиционировать библиотеку как замену STL, то и гарантии стоит сохранить

источник

10:28пожаловаться #6

АВ

Александр Вольнов in cxx.Дискуссионная

Александр Караев

Я выше написал - проблему бросающего исключения конструктора копирования/аллокатора/operator= это не решает

Почему не решает? Если мы копируем, а не переносим, мы можем просто удалить новую аллокацию, оставив старую нетронутой. Это и будет strong exception safety guarantee. А если мы перемещали и вылетел эксепшен, не факт, что мы сможем успешно переместить всё назад, чтобы откатить.

источник

10:28пожаловаться #7

/¯

/dev/urandon ¯\_(ツ)_/¯ in cxx.Дискуссионная

Александр Вольнов

Сначала всё делалось для себя под свои проекты, где у меня исключения вообще не используются. Но потом я всё-таки задумался о том, что надо сделал как надо, чтобы мою либу юзали и даже у себя таску отметил об exception safety. Но пока ещё не успел её сделать. Если в move конструкторе вылетит исключение, скорее всего будет UB и креш, даже базовой гарантии сейчас нет.

Был пункт 2 про расширение итераторов и ренджей. Какими средствами предполагается это сделать?

источник

10:29пожаловаться #8

АК

Александр Караев in cxx.Дискуссионная

Александр Вольнов

Почему не решает? Если мы копируем, а не переносим, мы можем просто удалить новую аллокацию, оставив старую нетронутой. Это и будет strong exception safety guarantee. А если мы перемещали и вылетел эксепшен, не факт, что мы сможем успешно переместить всё назад, чтобы откатить.

Не решает автоматически. Код-то написать придётся

источник

10:29пожаловаться #9

/¯

/dev/urandon ¯\_(ツ)_/¯ in cxx.Дискуссионная

Александр Вольнов

Почему не решает? Если мы копируем, а не переносим, мы можем просто удалить новую аллокацию, оставив старую нетронутой. Это и будет strong exception safety guarantee. А если мы перемещали и вылетел эксепшен, не факт, что мы сможем успешно переместить всё назад, чтобы откатить.

Есть Traversable обобщающийся не только на последовательные данные, но и на иерархичные

источник

10:30пожаловаться #10

АВ

Александр Вольнов in cxx.Дискуссионная

Александр Караев

О том и речь - более специфические контейнеры могут быть быстрее менее специфических, но дают меньше гарантий. Если уж позиционировать библиотеку как замену STL, то и гарантии стоит сохранить

Это лечится проверками на noexcept конструктор. Для тех типов, которые я использую, с noexcept-конструкторами , медленнее не станет.

источник

10:30пожаловаться #11

АК

Александр Караев in cxx.Дискуссионная

Александр Вольнов

Почему не решает? Если мы копируем, а не переносим, мы можем просто удалить новую аллокацию, оставив старую нетронутой. Это и будет strong exception safety guarantee. А если мы перемещали и вылетел эксепшен, не факт, что мы сможем успешно переместить всё назад, чтобы откатить.

И тогда уж сразу стоит изучить ситуацию, аналогичную этой:

std::vector<T> v{ T{}, T{}, T{} };
v.insert(v.begin() + 1, v.begin(), v.end())

источник

10:31пожаловаться #12

АВ

Александр Вольнов in cxx.Дискуссионная

Александр Караев

Не решает автоматически. Код-то написать придётся

Код по-любому писать надо. Это пара строчек по идее. Я когда закончу рефакторинг, займусь ликвидацией TODO'шек типа этой и всё сделаю.

источник

10:31пожаловаться #13

/¯

/dev/urandon ¯\_(ツ)_/¯ in cxx.Дискуссионная

Александр Вольнов

Почему не решает? Если мы копируем, а не переносим, мы можем просто удалить новую аллокацию, оставив старую нетронутой. Это и будет strong exception safety guarantee. А если мы перемещали и вылетел эксепшен, не факт, что мы сможем успешно переместить всё назад, чтобы откатить.

Еще чтоб получить идеальную композируемость, вместе с Traversable нужны линзы, призмы, изоморфизмы, фолды и траверсы

источник

10:33пожаловаться #14

/¯

/dev/urandon ¯\_(ツ)_/¯ in cxx.Дискуссионная

Тогда останется только дождаться рефлексии в стандарте, можно будет генерить линзы автоматом

источник

10:34пожаловаться #15

АВ

Александр Вольнов in cxx.Дискуссионная

/dev/urandon ¯\_(ツ)_/¯

Был пункт 2 про расширение итераторов и ренджей. Какими средствами предполагается это сделать?

Различные генераторы, декораторы типа Filter, Map, а также алгоритмы типа Reduce. Оно есть и в C++20 ranges, но у меня гораздо больше разных. И написать самому проще простого, простейший класс с тремя методами First(), Empty(), PopFirst - не надо даже шаблонов, наследования и адаптеров, как ranges от Эрика.

источник

10:37пожаловаться #16

АВ

Александр Вольнов in cxx.Дискуссионная

/dev/urandon ¯\_(ツ)_/¯

Еще чтоб получить идеальную композируемость, вместе с Traversable нужны линзы, призмы, изоморфизмы, фолды и траверсы

Куча незнакомых слов. Если про изоморфизмы, фолды и траверсы можно догадаться что это, то про линзы и призмы впервые слышу. Что это?

источник

10:38пожаловаться #17

АВ

Александр Вольнов in cxx.Дискуссионная

/dev/urandon ¯\_(ツ)_/¯

Тогда останется только дождаться рефлексии в стандарте, можно будет генерить линзы автоматом

Да, я уже лет 5 жду рефлексию.

источник

10:39пожаловаться #18

А

Андрей in cxx.Дискуссионная

ребят, хочу написать убийцу плюсов, с чего начать?

источник

10:40пожаловаться #19

/¯

/dev/urandon ¯\_(ツ)_/¯ in cxx.Дискуссионная

Александр Вольнов

Куча незнакомых слов. Если про изоморфизмы, фолды и траверсы можно догадаться что это, то про линзы и призмы впервые слышу. Что это?

Это profunctor optics всё.
Линза по сути, это объект объединяющий геттер и сеттер, который композируется с другими такими же объектами

источник

10:42пожаловаться #20