Комментарии 49
И чем отличается новый System.Runtime.InteropServices.NativeMemory.Alloc(x) от старого System.Runtime.InteropServices.Marshal.AllocHGlobal(x)
Нагуглил аналогичный вопрос: https://devblogs.microsoft.com/dotnet/new-dotnet-6-apis-driven-by-the-developer-community/#comment-10236
Вкратце ответ:
"Marshal.AllocHGlobal по документации должна (что не может быть изменено чтобы не ломать обратную совместимость) вызывать LocalAlloc Win32. LocalAllocAPI считается легаси и не рекомендуется к использованию в современных приложениях
С другой стороны NativeMemory.Alloc по документации является сравнительно тонкой обёрткой над malloc. Соответственно она должна быть быстрее и более совместимой со стандартной логикой выделения/возвращения памяти в современных приложениях"
Да и смысл, если есть nullable context.
Nullable типы не являются стопроцентной защитой, т.к. а) выдают ворнинги, а не ошибки компиляции, б) могут быть подавлены восклицательнвм знаком, в) компилятор иногда ошибается в определении nullability, г) бесполезны при вызове из контекста с отключенными nullable типами. Поэтому, чтобы не отхватить NRE в неожиданном месте, может потребоваться дополритеььный контроль входных параметров
Ну не отхватишь NRE в том месте, где он падает, отхватишь в начале метода. В обоих случаях все равно полезешь смотреть StackTrace и исправлять баг.
Как бы да, nullable context пока форсированно не внедрен, но, во первых, никто не запрещает поставить соответствующий флаг компиляции, а во-вторых, он решают проблему на корню, вместо того чтобы писать тонны костылей в виде ThrowIfNull.
У этих двух способов есть небольшое различие в том, как считается тестовое покрытие: в вашем способе надо два теста, чтобы обеспечить 100% покрытие, а в способе из статьи - достаточно одного.
Оставим за скобками целесообразность расчёта этого показателя. На некоторых проектах требования по уровню покрытия внедрены в пайплайн сборки, и хочешь не хочешь, но вынужден соблюдать требования
а ещё можно сделать метод-расширение вида obj.NotNull()
Отчего ж не верить. Аналогичные вещи бывают в каждом первом проекте.
Другое дело что лучше сделать что-то вида T NotNull<T>(this T obj) where T : class
Примерно затем же, что и автосвойства: язык предоставляет возможность более компактно описать решения для распространённых задач. А коль скоро стандартная библиотека не предлагает нормальных средств для этого, рождаются такие вот костыли.
Настолько компактно, что бесполезно. Что Вы дальше с этой проверкой делать собираетесь? Вот это дальше уже можно и выносить куда-то в тихое место.
Мы добавили помощник, чтобы упростить сброс, если отсутствует требуемый раздел конфигурации
Моя не понимать что значить "помошник" и "сброс"
лучше бы добавили поддержку record-ов для конфигурационных моделей, делов-то конструктор вычитать.
да, и вообще IConfiguration не удобен, банально когда нужно достать конфиг во время DI регистраций, там уже нужно танцевать или делать что то на конвеншенах
Если речь про ASP.NET Core, то там есть хак, которым сами MS часто пользуются. Поскольку IConfiguration лежит в IServiceCollection в виде инстанса, то можно его просто оттуда достать и использовать. Такая же тема с IHostEnvironment. Такой хак позволяет иногда сильно упростить сигнатуры методов.
то что его можно инжектить это понятно, я про использование его в ConfigureServices, а еще хуже когда у вас екстеншн метод от другой библиотеки services.AddSomeService("section"), где как должна выглядеть секция знает только дока
Ну нет, "где и как лежит", если речь про конфиг-хранилище, то задача это достать и распарсить лежит на том, кому это хранилище принадлежит, обычно это исполняемая (exe) сборка. А если у вас "другой библиотеке" требуется какая-то конфигурация, то она должна "попросить" ее через свой интерфейс или тот же record.
Получить IConfiguration не проблема, проблема "заглянуть" внутрь — потому что биндер до опций на этом этапе ещё не настроен.
public static List<List<T>> ChunkByCount<T>(this List<T> msgs, int count){ return msgs .Select((x, i) => new { Index = i, Value = x }) .GroupBy(x => x.Index / count) .Select(x => x.Select(v => v.Value).ToList()) .ToList();}
вот и всё прощай мой самый залайканый код на стэковерфлове
Но это же ужас, а не код. Столько лишних действий...
че ты пишешь? открой новый нативный и удивись. вернёшься и мне лайк еще поставишь...
"Нативный" — это какой? Если вы про вот эти — Chunk.cs#L55-L78 и Chunk.SpeedOpt.cs#L11-L37 — то они гораздо оптимальнее работают.
Группировка, потом ToList, потом ToList, да и зачем вообще List возвращать в коде; сложность — что по CPU, что по памяти, в итоге хорошо если O(3N)?
Картинка на превью меня все же настораивает, если предполагаете писать кросс-платформненое приложение с использованием MAUI, то что будет с Blazor hybrid mobile, так как мы его уже выбрали?
Новые API в .NET 6