Yet Another C++ Developerтекст ещё не в индексе
А если сверху у нас obj : Obj = (тренарник) то уже надо наоборот
2 августа 2026
だーく ほーるА если сверху у нас obj : Obj = (тренарник) то уже надо наоборот
и правда. что то не сразу получилось про это вспомнить. и правда как в расте
だーく ほーるтекст ещё не в индексе
Я думаю, что смешивать ссылочность с типами вредно, особенно когда типы могут приводиться друг к другу
Андреев КириллЯ думаю, что смешивать ссылочность с типами вредно, особенно когда типы могут приводиться друг к другу
Согласен, вот я и говорю что плохая идея
だーく ほーるИ в целом у нас получается typeof(тернарник) = Obj | Obj&
ну через | задавать в общем случае эт такое себе. а только для тернарника это делать с зависимостью от итогового это какие то костыли. тогда уж можно запретить прямой вывод типов для такого вида выражений (или сделать его непрямым).
всеволод ассемблертекст ещё не в индексе
Минусы коровы? Отсутствие прямого контроля и soundness. Больше навязанных рантаймом операций. В некоторых случаях больший расход памяти.
だーく ほーるИ в целом у нас получается typeof(тернарник) = Obj | Obj&
или можно сделать иначе — & пробрасывает ток на один уровень выражения. тогда с тернарниками они всегда будут 1 тип иметь.
Yet Another C++ Developerили можно сделать иначе — & пробрасывает ток на один уровень выражения. тогда с тернарниками они всегда будут 1 тип иметь.
Да, тоже выход, но мне кажется что для большинства целей проще иметь явные указания, а не пытаться приводить одно к другому
だーく ほーるЭээ, а как cow ломает саунднесс🤔
AutoCoW как например в Swift — однозначно. Это совершенно непредсказуемое поведение компилятора, когда он везде и всегда заворачивает всё в CoW, за исключением ситуаций когда не заворачивает. Это полностью ломает мутабельность, ибо много непредсказуемых ситуаций, меняющихся от версии к версии реализации компилятора.
Alex 🫣AutoCoW как например в Swift — однозначно. Это совершенно непредсказуемое поведение компилятора, когда он везде и всегда заворачивает всё в CoW, за исключением ситуаций когда не заворачивает. Это полностью ломает мутабельность, ибо много непредсказуемых ситуаций, меняющихся от ве
Что еще за Auto? Cow в swift и jvm языках совсем разные вещи
だーく ほーるДа, тоже выход, но мне кажется что для большинства целей проще иметь явные указания, а не пытаться приводить одно к другому
ну плюсы как то живут с приведением одного в другое и всякое
Yet Another C++ Developerну плюсы как то живут с приведением одного в другое и всякое
Плюсы, как мне кажется, можно использовать в качестве примера "как не надо делать"
Alex 🫣AutoCoW как например в Swift — однозначно. Это совершенно непредсказуемое поведение компилятора, когда он везде и всегда заворачивает всё в CoW, за исключением ситуаций когда не заворачивает. Это полностью ломает мутабельность, ибо много непредсказуемых ситуаций, меняющихся от ве
Вы что-то путаете, там cow явный через функцию isKnownUniquelyReferenced которая внутри просто смотрит на счетчик сильных ссылок. Cow явно обозначен в стд либе и есть только у трех коллекций в ней. А у просто структур и даже циклических indirect enum никакого встроенного cow нет. Это если мы говорим о cow как о термине который вводят авторы swift.
Yet Another C++ Developerтаки почему
Я ж в личку тебе писал год назад. Нас тогда из какого-то чата отправили сраться куда-нибудь ещё
Андреев КириллЯ ж в личку тебе писал год назад. Нас тогда из какого-то чата отправили сраться куда-нибудь ещё
ничоси вы помните то чо было год назад
Yet Another C++ Developerничоси вы помните то чо было год назад
У вас в никнейме "С++" написано, такое я забыть не в состоянии
Alex 🫣AutoCoW как например в Swift — однозначно. Это совершенно непредсказуемое поведение компилятора, когда он везде и всегда заворачивает всё в CoW, за исключением ситуаций когда не заворачивает. Это полностью ломает мутабельность, ибо много непредсказуемых ситуаций, меняющихся от ве
Если вы про ситуацию при копировании обычных структур, то там оптимизация копии не часть семантики и закладываться на это не нужно. А если нужно явно убрать копии у value типов, то нужно использовать consume и inout/borrowing/consuming
https://www.amazon.com/Theory-Objects-Monographs-Computer-Science/dp/0387947752 рекомендую всем этот талмуд, если будете делать что-то объектно-ориентированное
АндрейЕсли вы про ситуацию при копировании обычных структур, то там оптимизация копии не часть семантики и закладываться на это не нужно. А если нужно явно убрать копии у value типов, то нужно использовать consume и inout/borrowing/consuming
Вы же понимаете, что это костыль, появившийся, кстати, позже чем вот это неявное копирование всего.
Если что, я не апологет Очевидности и чаще многих употребляю RTFM, но эту непредсказуемую навязываемую неявность (далеко не только в Свифте) не могу назвать адекватной, рациональной и часто управляемой.
Пример помню... Есть значение типа Опшнл КакаятоСтруктура. Нужно прям тут изменить значение одного из полей структуры. Очевидный struct?.field = 11 вариант, на сколько помню, приводит к копированию на матчинге внутри сахара и новое значение пишется в копию, которая сразу и удаляется.