24 декабря Архивач восстановлен после серьёзной аварии. К сожалению, значительная часть сохранённых изображений и видео была потеряна. Подробности случившегося. Мы призываем всех неравнодушных помочь нам с восстановлением утраченного контента!
>>2970750 >Чтобы не копировать массив для возвращения, а вернуть указатель на уже выделенную ячейку памяти Так ты и так это сделаешь вернув List. List ссылочный тип и при передаче передается только ссылка на него. Прочитай про ссылочные и значимые типы в C# >>2969825 (OP) >Кто-нибудь знает как мне стоит правильнее написать? 1) Выкинь все ref нахуй (вообще все) 2) В первом if можешь просто написать return new List<int>{0};
Остальное не смотрел, единственное, что - назвавния переменных пиздец, отвыкай так писать.
>>2970947 ref это для параметров метода, чтобы можно было их внутри метода поменять, и чтобы это изменение можно было увидеть снаружи. Это аналог передачи по ссылке.
Тебе надо врубиться в разницу между типами-значениями и типами-ссылками. Загугли и почитай.
>>2969825 (OP) Ты можешь использовать указатели, как в си. Там в настройках проекта надо разрешить небезопасный код и в самом коде перед функцией ключевое слово unsafe написать. Тогда, на сколько помню, всё будет по человечески, как в сях
На самом деле еще орнее чем ОП долбоеб, долбоебский С++ создающий копии коллекций при каждом пуке. И эти опущи рассказывают сказки как они заботятся о производительности.
>>2974020 Я люблю создавать дип копии. Каждый день пишу код с дип копиями. Нужно передать объект в функцию? Я создаю дип копию! Нужно вернуть коллекцию? Я создаю дип копию! Поменять один элемент массива? Ну это же очевидно, надо просто создать дип копию!
>>2969825 (OP) Личрали: >у долбоеба забрали дробовик за ненадобностью и чтобы не застрелил себя случайно >хмм... ребят, а где здесь у вас дробовик можно найти???
В шарпе - есть ссылочные типы(reference type) и значимые типы(value type).
Классы, рекорды - ссылочные типы. Структуры - значимые типы.
Семантика простая - для значимых типов ты всегда передаешь копию. Для ссылочных - ты передаешь копию ссылки на объект.
Убедиться в этом можно довольно просто. Например прикриплейд. Массив - в шарпе ссылочного типа. Потому - я могу изменить что-то в массиве и это повлияет на объект который был снаружи. Но если бы я выполнил присвоение для аргумента, это не повлечет переприсование значения. Потому что передана копия ссылки, а не оригинальная ссылка. Ну, тут думаю понятно.
Дальше. ref используется, когда в методе тебе прям нужна оригинальная ссылка, например - если метод может переопределить значение по ссылке внутри себя, либо если это структура, которую ты хочешь модифицировать в теле метода(помним, что структуры - значимые, а потому копируются, вот тут работает почти так же как в си/си++).
Например
void foo(ref MyClass a){ if(NotValid(a)) a = new MyClass(); }
В таком случае - передастся не копия ссылки, а оригинальная ссылка на объект, и переприсвоив значение - ты изменишь значение снаружи. Это крайне редко надо, потому.
Для случаев, когда это надо - обычно используется out для аргументов функции. Это более явно и компилятор будет прверять, что ты таки не забыл присвоить значение в теле метода. Для случаев, когда тебе наоборот - не нужно ничего по ссылке изменять - есть модификатор in, например, тебе для рассчетов надо передавать структуру, ты не будешь ее менять, но не хочешь постоянно копировать - используешь int foo(in MyStruct a, in MyStruct b);
Дополнительно, для сишника надо еще объяснить про упаковку-распоковку. Но уже как-то лень. Да и я хуевый объяснятор.
>>2970947 Неправильно. new это вызов конструктора. А что он вернет - зависит от того что ты там создал. Для структуры - он вернет честно шарповскую структуру. Для классов-рекордов - ссылку.
Если тебе так хочется с сишкой ассоциации иметь.
То это что-то в духе
// для класса some✼ create_some() { some✼ ptr = malloc(sizeof some); some_ctor(ptr); return ptr; }
// для структуры some create_some(){ some item = {0}; some_ctor(✼item); return item; }
>>2975505 Спасибо за объяснение. Это на самом деле многое объясняет, но также и усложняет.
Если базовые идеи in, ref, out по-сути своей работают также как ✷ или & в с/с++ то в чем смысл? Или это своего рода подсказка для компилятора, что вот ты использовал in а значит прописывать машинный код на случай изменения данных не нужно? Типо как подсказки inline или noexcept или constexpr в с++?
>>2979503 >Если базовые идеи in, ref, out по-сути своей работают также как ✷ или & в с/с++ то в чем смысл? Забудь про in, ref, out. Это всё уродливая хуйня, которая больше не нужна. Теперь есть удобные кортежи, даже с именами, например (int result, string message), которые можно возвращать из методов. По существу: указатели в C# это исключительно в блоке unsafe. Это надо только там, где у тебя пиздец бутылочное горлышко по производительности. ref это то же самое, что & в сях out это если тебе недостаточно вернуть одно значение. Как я написал, для этого теперь есть кортежи.
>>2979525 >Как я написал, для этого теперь есть кортежи. Хуйню несешь. Взять какой нибудь условный TryParse — этот метод возвращает bool как результат успешности операции, но в out идет результат парсинга. Именно поэтому возможно удобным способом впихнуть метод в качестве условия проверки if, что будет очень геморно с обоссаными кортежами.
if (TryParse(zalupa, out int udobnayaZalupa)){ result = udobnayaZalupa + pizda; }
>>2979525 >указатели в C# это исключительно в блоке unsafe. Это надо только там, где у тебя пиздец бутылочное горлышко по производительности. Не только. Если понадобится дергать какие-нибудь нативные библиотеки (например при работе с криптографией) то без этого не обойтись.
>>2983430 >j_j ничего не понял из этого синтаксиса Тут много выебонов просто. Суть первого скрина в том, что есть nullable типы, например int?. Он может содержать число или null. Соответственно метод Parse может вернуть null если распарсить не удалось, то есть два значения умещаются в одну переменную. Ещё у него там метод в виде стрелочной функции, но это к теме отношения не имеет.
На втором скрине новые кортежи, которые объявляются в виде (T1 var1, T2 var2, ...) вместе с деконструкцией. То бишь var1, var2 ит.д. можно использовать вне кортежа как самостоятельные переменные. Кортеж по-английски будет tuple, если погуглить решишь.
Если честно, с моей точки зрения этот сахар уже на грани того, где он вместо повышения читаемости за счёт сокращения кода, будет её понижать из-за изобилия магических значков.
>>2983550 В твоем посте описание пикрил 1 >>2983425 >Суть первого скрина в том, что есть nullable типы, например int?. Он может содержать число или null. Соответственно метод Parse может вернуть null если распарсить не удалось, то есть два значения умещаются в одну переменную.
>>2983567 >возвращают null в качестве идентификатора успеха >>2983567 >вернуть null если распарсить не удалось Анон, ты неправильно читаешь. И такая штука используется повсеместно в стандартной (и не очень) библиотеке 🥗. Тот же FirstOrDefault() абсолютно так же возвращает либо объект, либо default (null)
>>2983795 >Анон, ты неправильно читаешь. Я имел ввиду идентификацию успешности, которая может быть положительной, так и отрицательной.
>Тот же FirstOrDefault() абсолютно так же возвращает либо объект, либо default (null) Нет, метод возвращает то, что ты указал. И если ты всунул null в default, то сам виноват. В данном случае обязанности перекладываются с метода на тебя, но это не значит, что ты должен туда засовывать null, иначе смысл данного метода теряется.
В общем и целом такой подход (возврат null ) не является правильным по многим причинам: а) null может являться нормальным состоянием возвращаемой переменной б) у типов есть свои кастомные состояния: - string.Empty - double.NaN - Binding.DoNothing - DependencyProperty.UnsetValue И эти состояния куда безопаснее. Например возврат пустого массива никак не затронет работоспособность последующего цикла перебора этого массива. Даже если я где-то прощелкаю проверку, это не вызовет исключение. Именно поэтому существуют методы типа FirstOrDefault(), чтобы ты туда поместил состояние подходящее конкретно для обрабатываемого типа. в) отсутствие стандарта, из-за чего одни надо проверять на нал, другие на бул, третьи еще как-то. Это может привести к непредвиденным переусложнениям. А булевое значение достаточно примитивное и суперуниверсальное решение. Если уж так хочется, то возвращай кортежи через out.
>>2983918 >иначе смысл данного метода теряется. Смысл FirstOrDefault() обеспечить бесперебойность работы. Метод должен вернуть любое работающее значение. Например ты читаешь сеттингсы из файла, а в файле данного параметра нет, но ты все равно выводишь дефолтное значение.
Когда ты возвращаешь null, то руинишь саму идею метода (кроме случаев из пункта a), когда null является нормальным состоянием)
>>2983918 а) null не должен являться нормальным состоянием возвращаемой переменной б) для этого и существуют - string.Empty - double.NaN - Binding.DoNothing - DependencyProperty.UnsetValue в) возвращение була это некрокал из 80х, когда это и вместо исключений использовалось. Не надо выносить реализацию в интерфейс
>>2984011 >null не должен являться нормальным состоянием возвращаемой переменной Но переменная может иметь null в качестве нормального состояния. Тогда возврат null методом в качестве неудачи даст неоднозначность.
>для этого и существуют Чтобы ты не использовал нал
>возвращение була это некрокал из 80х Это твое дело. Создание исключение дорогостоящая операция, в отличии от возврата булевого состояния. Вероятно ты не задумываешься о бущуем своего метода. Я не говорю, что исключения не нужны, я говорю о том, что всему есть место. Будучи Белый Медведьом метода FirstOrDefault(), ты уверен в том как и где этот метод будет использоваться? Не будут ли тебя проклинать те, кто будет использовать твой метод, например, в анимации?
Я вот пидорасам, возвращающих исключения в асинхронных методах, желаю исключительно рака. Потому что этот кал не обработать никак.
>>2984081 >Но переменная может иметь null в качестве нормального состояния Синтаксически? Да. Семантически? Нет. >Тогда возврат null методом в качестве неудачи даст неоднозначность. Если для тебя не однозначно что значит null, возвращённый методом, который парсит строку в число, то проблемы с тобой, а не с нуллом.
народ,такая хуйня,внутри редактора юнити игра играется нормально а когда собираю в билд анимации гг ломаются и движется хуй пойми как,кто нибудь знает с чем может быть связанно?
>>2985857 Я думал там будет что-то прям существенно важное связанное с возвращением указателя или с синтаксисом (проблема или предупреждение после компиляции)
>>2970748 Во первых если тебя интересуют адреса, то нужно работать с указателями. А чтобы с ними работать нужно ли компилятор C# глобально настроить с работой небезопасного когда. Либо некий код заключить в unsafe{ некий код}.
Всё нахуй. Дальше же ты С знаешь.
Но в С# нахуй не надо это в целом. Смирись и запомни концепцию значимых и ссылочных типом, так даже проще мыслить когда пишешь C#.
На скринах я хочу добиться похожего для C# как на С. Кто-нибудь знает как мне стоит правильнее написать?