На скринах я хочу добиться похожего для C# как на С. Кто-нибудь знает как мне стоит правильнее написать?
Ты дебил? Я поэтому и спрашиваю как написать так, чтобы работало как на С
Чтобы не копировать массив для возвращения, а вернуть указатель на уже выделенную ячейку памяти
>Чтобы не копировать массив для возвращения, а вернуть указатель на уже выделенную ячейку памяти
Так ты и так это сделаешь вернув List. List ссылочный тип и при передаче передается только ссылка на него.
Прочитай про ссылочные и значимые типы в C#
>>2969825 (OP)
>Кто-нибудь знает как мне стоит правильнее написать?
1) Выкинь все ref нахуй (вообще все)
2) В первом if можешь просто написать return new List<int>{0};
Остальное не смотрел, единственное, что - назвавния переменных пиздец, отвыкай так писать.
Я правильно тогда понимаю, что инструкция new как и в С++ возвращает не сам объект, а скорее адрес на созданный объект?
И тогда получается правильно будет интерпретировать
public List<int> f() {
return new List<int>();
}
как
int f() {
return (int)malloc(sizeof(int));
}
так ведь?
А ref будет тогда использоваться токо в качестве параметра для функций для избежания лишнего копирования данных, так?
ref это для параметров метода, чтобы можно было их внутри метода поменять, и чтобы это изменение можно было увидеть снаружи.
Это аналог передачи по ссылке.
Тебе надо врубиться в разницу между типами-значениями и типами-ссылками. Загугли и почитай.
Ты можешь использовать указатели, как в си. Там в настройках проекта надо разрешить небезопасный код и в самом коде перед функцией ключевое слово unsafe написать. Тогда, на сколько помню, всё будет по человечески, как в сях
Я люблю создавать дип копии. Каждый день пишу код с дип копиями. Нужно передать объект в функцию? Я создаю дип копию! Нужно вернуть коллекцию? Я создаю дип копию! Поменять один элемент массива? Ну это же очевидно, надо просто создать дип копию!
Личрали:
>у долбоеба забрали дробовик за ненадобностью и чтобы не застрелил себя случайно
>хмм... ребят, а где здесь у вас дробовик можно найти???
Ты сначала ошибку в коде справа почиини-то.
А теперь пояснение.
В шарпе - есть ссылочные типы(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);
Дополнительно, для сишника надо еще объяснить про упаковку-распоковку. Но уже как-то лень. Да и я хуевый объяснятор.
Неправильно.
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;
}
Спасибо за объяснение. Это на самом деле многое объясняет, но также и усложняет.
Если базовые идеи in, ref, out по-сути своей работают также как ✷ или & в с/с++ то в чем смысл? Или это своего рода подсказка для компилятора, что вот ты использовал in а значит прописывать машинный код на случай изменения данных не нужно? Типо как подсказки inline или noexcept или constexpr в с++?
Походу ты вообще ни разу не сидел и не писал ничего на С/С++ и затираешь какую-то херь.
Иди почитай хотя бы про std::move() и учи нормальные языки, а не дичь по типу JavaScript или Python
>Если базовые идеи in, ref, out по-сути своей работают также как ✷ или & в с/с++ то в чем смысл?
Забудь про in, ref, out. Это всё уродливая хуйня, которая больше не нужна.
Теперь есть удобные кортежи, даже с именами, например (int result, string message), которые можно возвращать из методов.
По существу: указатели в C# это исключительно в блоке unsafe. Это надо только там, где у тебя пиздец бутылочное горлышко по производительности.
ref это то же самое, что & в сях
out это если тебе недостаточно вернуть одно значение. Как я написал, для этого теперь есть кортежи.
>Как я написал, для этого теперь есть кортежи.
Хуйню несешь. Взять какой нибудь условный TryParse — этот метод возвращает bool как результат успешности операции, но в out идет результат парсинга. Именно поэтому возможно удобным способом впихнуть метод в качестве условия проверки if, что будет очень геморно с обоссаными кортежами.
if (TryParse(zalupa, out int udobnayaZalupa)){
result = udobnayaZalupa + pizda;
}
>указатели в C# это исключительно в блоке unsafe. Это надо только там, где у тебя пиздец бутылочное горлышко по производительности.
Не только. Если понадобится дергать какие-нибудь нативные библиотеки (например при работе с криптографией) то без этого не обойтись.
тебе по-моему здесь реф вообще не нужен, это простейший слуГлинтвейн, просто возвращай sub_list
>(a, b) = (b, a)
Нахуй ты ньюфагов некроговну учишь? Если бы не обратная совместимость - про out уже давно бы все забыли
>j_j ничего не понял из этого синтаксиса
Тут много выебонов просто. Суть первого скрина в том, что есть nullable типы, например int?. Он может содержать число или null. Соответственно метод Parse может вернуть null если распарсить не удалось, то есть два значения умещаются в одну переменную.
Ещё у него там метод в виде стрелочной функции, но это к теме отношения не имеет.
На втором скрине новые кортежи, которые объявляются в виде (T1 var1, T2 var2, ...) вместе с деконструкцией. То бишь var1, var2 ит.д. можно использовать вне кортежа как самостоятельные переменные. Кортеж по-английски будет tuple, если погуглить решишь.
Если честно, с моей точки зрения этот сахар уже на грани того, где он вместо повышения читаемости за счёт сокращения кода, будет её понижать из-за изобилия магических значков.
Только кончи возвращают null в качестве идентификатора успеха. Ну или ньюфаки.
>Только кончи возвращают null в качестве идентификатора успеха. Ну или ньюфаки.
Что ты несешь, болезный?
Где ты такое в моём посте прочитал?
В твоем посте описание пикрил 1 >>2983425
>Суть первого скрина в том, что есть nullable типы, например int?. Он может содержать число или null. Соответственно метод Parse может вернуть null если распарсить не удалось, то есть два значения умещаются в одну переменную.
Ну наконец "правильно делай правильно будет"-копиум подъехал.
>std::move()
кривой костыль
>возвращают null в качестве идентификатора успеха
>>2983567
>вернуть null если распарсить не удалось
Анон, ты неправильно читаешь. И такая штука используется повсеместно в стандартной (и не очень) библиотеке 🥗. Тот же FirstOrDefault() абсолютно так же возвращает либо объект, либо default (null)
>Анон, ты неправильно читаешь.
Я имел ввиду идентификацию успешности, которая может быть положительной, так и отрицательной.
>Тот же FirstOrDefault() абсолютно так же возвращает либо объект, либо default (null)
Нет, метод возвращает то, что ты указал. И если ты всунул null в default, то сам виноват. В данном случае обязанности перекладываются с метода на тебя, но это не значит, что ты должен туда засовывать null, иначе смысл данного метода теряется.
В общем и целом такой подход (возврат null ) не является правильным по многим причинам:
а) null может являться нормальным состоянием возвращаемой переменной
б) у типов есть свои кастомные состояния:
- string.Empty
- double.NaN
- Binding.DoNothing
- DependencyProperty.UnsetValue
И эти состояния куда безопаснее. Например возврат пустого массива никак не затронет работоспособность последующего цикла перебора этого массива. Даже если я где-то прощелкаю проверку, это не вызовет исключение.
Именно поэтому существуют методы типа FirstOrDefault(), чтобы ты туда поместил состояние подходящее конкретно для обрабатываемого типа.
в) отсутствие стандарта, из-за чего одни надо проверять на нал, другие на бул, третьи еще как-то. Это может привести к непредвиденным переусложнениям. А булевое значение достаточно примитивное и суперуниверсальное решение. Если уж так хочется, то возвращай кортежи через out.
>иначе смысл данного метода теряется.
Смысл FirstOrDefault() обеспечить бесперебойность работы. Метод должен вернуть любое работающее значение. Например ты читаешь сеттингсы из файла, а в файле данного параметра нет, но ты все равно выводишь дефолтное значение.
Когда ты возвращаешь null, то руинишь саму идею метода (кроме случаев из пункта a), когда null является нормальным состоянием)
а) null не должен являться нормальным состоянием возвращаемой переменной
б) для этого и существуют
- string.Empty
- double.NaN
- Binding.DoNothing
- DependencyProperty.UnsetValue
в) возвращение була это некрокал из 80х, когда это и вместо исключений использовалось. Не надо выносить реализацию в интерфейс
>null не должен являться нормальным состоянием возвращаемой переменной
Но переменная может иметь null в качестве нормального состояния. Тогда возврат null методом в качестве неудачи даст неоднозначность.
>для этого и существуют
Чтобы ты не использовал нал
>возвращение була это некрокал из 80х
Это твое дело. Создание исключение дорогостоящая операция, в отличии от возврата булевого состояния. Вероятно ты не задумываешься о бущуем своего метода. Я не говорю, что исключения не нужны, я говорю о том, что всему есть место. Будучи Белый Медведьом метода FirstOrDefault(), ты уверен в том как и где этот метод будет использоваться? Не будут ли тебя проклинать те, кто будет использовать твой метод, например, в анимации?
Я вот пидорасам, возвращающих исключения в асинхронных методах, желаю исключительно рака. Потому что этот кал не обработать никак.
МЯУ. Лучше все через хер писать. О таких как ты будут вспоминать как о дегенератах с говнокодом.
>Но переменная может иметь null в качестве нормального состояния
Синтаксически? Да. Семантически? Нет.
>Тогда возврат null методом в качестве неудачи даст неоднозначность.
Если для тебя не однозначно что значит null, возвращённый методом, который парсит строку в число, то проблемы с тобой, а не с нуллом.
>Если для тебя не однозначно что значит null, возвращённый методом, который парсит строку в число, то проблемы с тобой, а не с нуллом.
>null на входе
>невалидный UTF-8
>невалидное число
>арифметическое переполнение
Нет, не очевидно.
Мимо проходил
>промазал пальцем
>недостаточно рам
>полетела винда
>умер дед
За корректность введённых данных отвечает юзер, а не Белый Медведь.
Да и вообще речь не об этом. Контекст треда вообще о другом. Пиши по теме пж.
Я думал там будет что-то прям существенно важное связанное с возвращением указателя или с синтаксисом (проблема или предупреждение после компиляции)
Во первых если тебя интересуют адреса, то нужно работать с указателями. А чтобы с ними работать нужно ли компилятор C# глобально настроить с работой небезопасного когда. Либо некий код заключить в unsafe{ некий код}.
Всё нахуй. Дальше же ты С знаешь.
Но в С# нахуй не надо это в целом. Смирись и запомни концепцию значимых и ссылочных типом, так даже проще мыслить когда пишешь C#.