(no subject)
Nov. 29th, 2018 01:27 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
yigal_sМудацкий С++ всегда забавен (особенно если хороошо забыть то, что знал когда-то).
Сто тридцать пятая попытка сделать смарт-поинтеры, в этот раз shared_ptr, которому, впрочем, сто лет в обед. Недостатки:
1. member-функция всё ещё имеет дело с raw-pointer 'this'. Хоть убейся. Т.е. о 100% безопасности кода речи и не идёт, всегда можно ненароком куда-то засунуть обычный указатель.
2. shared_ptr на тип не совместим с shared_ptr на константный тип или на базовый тип. Ну, т.е. прокастировать-то можно, но при этом будет зачем-то создаваться новый объект указателя. Боюсь, в рамках С++ это в случае наследования и решить нельзя, не выходя грубо за рамки стандарта. Остаётся только тупо копировать shared_ptr, что не очень дорого, но... жаба душит.
3. Если объект где-то расшерен, а у вас есть обычный указатель, то сделать из него снова shared ведёт к катастрофе. Ну, если такое действительно нужно, то можно как-то исхитриться, написать функцию-член класса give-me-shared(), которая воспользуется внутря shared_from_this. Ну всё же от тупого повторного вызова конструктора shared_ptr поверх указателя - как защититься? Конструктор-то публичный, производящий shared_ptr из обычного указателя - он, пусть и explicit, но всё равно открыт всем семи ветрам, поди потом по коду отследи где его вызывали.
4. shared_from_this из конструктора ведёт к undefined behavior (вроде в С++17 убрали). Как его не вызывать из конструктора - шерифа не волнует.
Культура отсутствия критики предусматривает, что подобную информацию вы можете насобирать по разным книгам или форумам, но никак не в централизованном виде на страницах документации. Everything is awesome.
ПС: а если поизвращаться, то во время компиляции хорошо б проверить, что указатели на базовый и производный класс совпадают по значению, и что размер shared_ptr совпадает для базового и производного класса (жалкая попытка убедиться в binary-compatibility), после всего для всех таких случаев сгенерить оператор кастирования в референс на smart_ptr на базовый тип...
Сто тридцать пятая попытка сделать смарт-поинтеры, в этот раз shared_ptr, которому, впрочем, сто лет в обед. Недостатки:
1. member-функция всё ещё имеет дело с raw-pointer 'this'. Хоть убейся. Т.е. о 100% безопасности кода речи и не идёт, всегда можно ненароком куда-то засунуть обычный указатель.
2. shared_ptr на тип не совместим с shared_ptr на константный тип или на базовый тип. Ну, т.е. прокастировать-то можно, но при этом будет зачем-то создаваться новый объект указателя. Боюсь, в рамках С++ это в случае наследования и решить нельзя, не выходя грубо за рамки стандарта. Остаётся только тупо копировать shared_ptr, что не очень дорого, но... жаба душит.
3. Если объект где-то расшерен, а у вас есть обычный указатель, то сделать из него снова shared ведёт к катастрофе. Ну, если такое действительно нужно, то можно как-то исхитриться, написать функцию-член класса give-me-shared(), которая воспользуется внутря shared_from_this. Ну всё же от тупого повторного вызова конструктора shared_ptr поверх указателя - как защититься? Конструктор-то публичный, производящий shared_ptr из обычного указателя - он, пусть и explicit, но всё равно открыт всем семи ветрам, поди потом по коду отследи где его вызывали.
4. shared_from_this из конструктора ведёт к undefined behavior (вроде в С++17 убрали). Как его не вызывать из конструктора - шерифа не волнует.
Культура отсутствия критики предусматривает, что подобную информацию вы можете насобирать по разным книгам или форумам, но никак не в централизованном виде на страницах документации. Everything is awesome.
ПС: а если поизвращаться, то во время компиляции хорошо б проверить, что указатели на базовый и производный класс совпадают по значению, и что размер shared_ptr совпадает для базового и производного класса (жалкая попытка убедиться в binary-compatibility), после всего для всех таких случаев сгенерить оператор кастирования в референс на smart_ptr на базовый тип...
no subject
Date: 2018-11-29 08:28 pm (UTC)no subject
Date: 2018-11-29 08:48 pm (UTC)Скажем, захотел юзер свои собственные указатели завести заместо стандартных - так чтоб вперёд и с песней.