C# (C Sharp) programming
По всем вопросам- @notxxx1 Реестр РКН: https://clck.ru/3Fk3kb #VRHSZ
Больше📈 Аналитический обзор Telegram-канала C# (C Sharp) programming
Канал C# (C Sharp) programming (@csharp_ci) языкового сегмента Русский является активным участником. Сейчас сообщество объединяет 18 144 подписчиков, занимая 7 070 место в категории Технологии и приложения и 36 441 место в регионе Россия.
📊 Показатели аудитории и динамика
С момента создания невідомо проект демонстрирует стремительный рост, собрав аудиторию из 18 144 подписчиков.
Согласно последним данным от 01 сентября, 2026, канал показывает стабильную активность. За последние 30 дней изменение числа участников составило -54, а за последние 24 часа — 20, при этом общий охват остаётся высоким.
- Статус верификации: Не верифицирован
- Уровень вовлечённости (ER): Средний показатель вовлечённости аудитории составляет 13.79%. В первые 24 часа после публикации контент обычно набирает 7.32% реакций от общего числа подписчиков.
- Охват публикаций: В среднем каждый пост получает 2 503 просмотров. В течение первых суток публикация набирает 1 329 просмотров.
- Реакции и взаимодействия: Аудитория активно поддерживает контент: среднее количество реакций на один пост — 0.
- Тематические интересы: Контент сосредоточен на ключевых темах, таких как .net, api, логика, архитектура, string.
📝 Описание и контентная политика
Автор описывает ресурс как площадку для выражения субъективного мнения:
“По всем вопросам- @notxxx1
Реестр РКН: https://clck.ru/3Fk3kb
#VRHSZ”
Благодаря высокой частоте обновлений (последние данные получены 02 сентября, 2026) канал поддерживает актуальность и высокий уровень охвата публикаций. Аналитика показывает, что аудитория активно взаимодействует с контентом, что делает его важной точкой влияния в категории Технологии и приложения.
int[] simpleArray = {0, 1, 2, 3, 4, 5, 6, 7, 8};
ref int simpleElementRef = ref simpleArray[3];
В этом примере simpleElementRef — ссылка на simpleArray[3]. Изменение simpleElementRef приводит к изменению элемента массива:
simpleElementRef *= 15; Console.WriteLine(simpleElementRef); // 15 Console.WriteLine(simpleArray[3]); // 15🟡В качестве цели ссылочной локальной переменной может быть указан элемент массива, поле, или обычная локальная переменная. Целью не может быть свойство. Ссылочные локальные переменные используются для специальных сценариев микро-оптимизации и как правило применяются в сочетании с возвращаемыми ссылочными значениями. 🟡Также ссылочные локальные переменные можно возвращать из методов. В результате получаем возвращаемое ссылочное значение:
static string X = "Старое значение";
static ref string GetX() => ref X; // Возвращает ссылочное значение
static void Main()
{
ref string xRef = ref GetX(); // Присваивает результат ссылочной локальной переменной
xRef = "Новое значение";
Console.WriteLine(X); // Выводит Новое значение
}
📎 Подробнее
@csharp_ciTask.Yield() возвращает специальное значение, предназначенное для передачи оператору await, и в отрыве от этого оператора не имеющее смысла.
Конструкция же await Task.Yield() делает довольно простую вещь — прерывает текущий метод и сразу же планирует его продолжение в текущем контексте синхронизации.
Используется же эта конструкция для разных целей.
🟡Во-первых, эта конструкция может быть использована для немедленного возврата управления вызывающему коду. Например, при вызове из обработчика события событие будет считаться обработанным:
protected override async void OnClosing(CancelEventArgs e)
{
e.Cancel = true;
await Task.Yield();
// (какая-то логика)
}
🟡Во-вторых, эта конструкция используется для очистки синхронного контекста вызова. Например, так можно "закрыть" текущую транзакцию (ambient transaction):
using (var ts = new TransactionScope()) {
// ...
Foo();
// ...
ts.Complete();
}
async void Foo() {
// ... тут мы находимся в контексте транзакции
if (Transaction.Current != null) await Task.Yield();
// ... а тут его уже нет!
}
🟡В-третьих, эта конструкция может очистить стек вызовов. Это может быть полезным, если программа падает с переполнением стека при обработке кучи вложенных продолжений.
Например, рассмотрим упрощенную реализацию AsyncLock:
class AsyncLock
{
private Task unlockedTask = Task.CompletedTask;
public async Task<Action> Lock()
{
var tcs = new TaskCompletionSource<object>();
await Interlocked.Exchange(ref unlockedTask, tcs.Task);
return () => tcs.SetResult(null);
}
}
Здесь поступающие запросы на получение блокировки выстраиваются в неявную очередь на продолжениях. Казалось бы, что может пойти не так?
private static async Task Foo()
{
var _lock = new AsyncLock();
var unlock = await _lock.Lock();
for (var i = 0; i < 100000; i++) Bar(_lock);
unlock();
}
private static async void Bar(AsyncLock _lock)
{
var unlock = await _lock.Lock();
// do something sync
unlock();
}
Здесь продолжение метода Bar вызывается в тот момент, когда другой метод Bar выполняет вызов unlock(). Получается косвенная рекурсия между методом Bar и делегатом unlock, которая быстро сжирает стек и ведет к его переполнению.
Добавление же вызова Task.Yield() перенесет исполнение в "чистый" фрейм стека, и ошибка исчезнет:
class AsyncLock
{
private Task unlockedTask = Task.CompletedTask;
public async Task<Action> Lock()
{
var tcs = new TaskCompletionSource<object>();
var prevTask = Interlocked.Exchange(ref unlockedTask, tcs.Task);
if (!prevTask.IsCompleted)
{
await prevTask;
await Task.Yield();
}
return () => tcs.SetResult(null);
}
}
@csharp_ci├╼ Устанавливаем .NET на Ubuntu 22.04
├╼ Создаём проект
├╼ Запускаем сборку в GitHub Actions
├╼ Используем секреты в коде тестов
╰╼ Размещаем секреты в GitHub Actions Secrets
📎 Туториал
🖥 GitHub
@csharp_ciFile:
[HttpGet("file/{guid}/download")]
[ProducesResponseType(StatusCodes.Status200OK)]
public async Task<IActionResult> DownloadFile([FromRoute] Guid guid)
{
var file = await _mediaContentService.DownloadFile(guid);
return File(file.Stream, file.ContentType, file.FileName);
}
Можно ли каким-либо образом реализовать ограничение на скачивание файла, чтобы, например, в единицу времени не больше N пользователей качало файл?
▶️Проблема с методом File — он возвращает ленивый ответ. Т.е. он не читает весь поток сразу, а ждет пока будет вызван метод от IActionResult.
Чтобы эту проблему решить, надо знать, когда файл точно отправлен.
Можно сделать специальный декоратор. Например:
[ApiController]
[Route("[controller]")]
public class SampleController : ControllerBase
{
private readonly IRateLimiter _rateLimiter;
public SampleController(IRateLimiter rateLimiter)
{
_rateLimiter = rateLimiter;
}
[HttpGet("connection")]
public async Task<IActionResult> DownLoadFile(Guid file)
{
var stream = await GetFileStream(file);
return new RateLimiterFileActionResult(File(stream, "content/type", "sample.txt"), _rateLimiter);
}
}
class RateLimiterFileActionResult : IActionResult
{
private readonly IActionResult _actionResultImplementation;
private readonly IRateLimiter _rateLimiter;
public RateLimiterFileActionResult(IActionResult actionResultImplementation, IRateLimiter rateLimiter)
{
_actionResultImplementation = actionResultImplementation;
_rateLimiter = rateLimiter;
}
public async Task ExecuteResultAsync(ActionContext context)
{
try
{
await _rateLimiter.ObtainAsync(context.HttpContext.RequestAborted);
await _actionResultImplementation.ExecuteResultAsync(context);
}
finally
{
await _rateLimiter.ReleaseAsync(context.HttpContext.RequestAborted);
}
}
}
public interface IRateLimiter
{
public Task ObtainAsync(CancellationToken token);
public Task ReleaseAsync(CancellationToken token);
}
Стоит заметить, что блокировка берётся внутри метода декоратора, а не в методе контроллера.
@csharp_ciout даёт такой же результат, как и с ref.
Такой код:
private void func(out string value)
{
value = "Hello World!";
}
Даёт такой же эффект, как и:
private void func(ref string value)
{
value = "Hello World!";
}
В чём же разница между out и ref?
▶️Разница в том, что out — это выходной параметр, а ref — входно-выходной.
Для ref-параметра вы должны передать его инициализированным, и можете пользоваться его исходным значением. А для out-параметра вы не обязаны инициализировать его перед вызовом функции, не можете использовать его значение в функции до присваивания, и обязаны инициализировать его в функции.
(Таким образом, ref-параметр немного напоминает инициализированную локальную переменную, а out-параметр — неинициализированную.)
Иллюстрация:
private void func1(out string value)
{
Console.WriteLine(value); // нельзя, value не инициализировано
if (false)
return; // нельзя, забыли установить значение value
value = "Hello World!";
}
string s1;
func1(out s1);
private void func2(ref string value)
{
Console.WriteLine(value); // можно
if (false)
return; // не проблема, у value остаётся старое значение
value = "Hello World!";
}
string s2;
func2(ref s2); // нельзя, функция имеет право использовать значение,
// значит, оно должно быть инициализировано сначала
Таким образом, out-параметр — это как бы дополнительное возвращаемое значение функции. А ref-параметр — просто параметр, изменения которого видны снаружи функции.
@csharp_cinull или пустую коллекцию? Есть ли общепринятая практика?
▶️Вопрос здесь в семантике.
На запрос «дайте мне список всех пользователей» пустая коллекция имеет очевидный смысл: «окей, вот вам список всех пользователей, их ровно 0 штук».
С другой стороны, возвращённый null может означать что угодно: «я не знаю, сколько пользователей», «количество пользователей ещё не подсчитано», «текущая база данных вообще не имеет понятия пользователь», что угодно.
То есть смысл пустой коллекции всегда ясен, смысл null не определён.
▶️Ещё одна причина возвращать пустые коллекции, а не null — так вы избавите пользователя от необходимости писать утомительный код проверок на null и, соответственно, избавите его от большого количества NullReferenceException, если он таковой код написать забыл. Хорошим примером могут быть случаи, когда коллекции задействованы в цепочках методов вида
var res = FirstMethod().SecondMethod().ThirdMethod();и в случае, если коллекция равна
null, вся цепочка может быть обрушена исключением, тогда как проверки на null превратят этот лаконичный и довольно элегантный синтаксис в кашу из вложенных if-ов. Для коллекций это можно считать общепринятой практикой.
Кстати, в LINQ именно так и делается. Например, следующий код вполне нормально работает без выбрасывания исключений, хотя очевидно, что ни один из элементов коллекции не удовлетворяет условию лямбды в Where:
var res2 = new[] { 1, 2, 3 }.Where(x => x > 10).Select(x => x);
@csharp_cievent и delegate — это 2 абсолютно разных вещи. Разница между полем-делегатом и event'ом примерно такая же, как между полем и свойством: event иногда выглядит как делегатное поле. Давайте разберёмся в этом.
⏩delegate — это класс, содержащий в себе «шаблон» метода, то есть, сигнатуру метода. Переменная делегатного типа — объект типа MulticastDelegate (точнее, производного от него), который может содержать один или несколько объектов, представляющих собой методы с совместимой с «шаблоном» сигнатурой (контр- и ковариантность немного усложняет картину). То есть это как бы переменная, которая может содержать функции. Для таких переменных определена операция +, которая комбинирует слагаемые-функции в одну новую функцию, и симметричная операция -. Эти операции автоматически порождают производные операции += и -=.
⏩event же — это просто пара методов в классе, обозначаемых как add и remove, и имеющих произвольную семантику, выбранную программистом. (Аналог — геттер и сеттер свойства.) В имплементации по умолчанию для event'а заводится скрытое поле делегатного типа, а add/remove добавляют или убирают из него методы (под lock'ом). (Чтобы немного запутать картину, это скрытое поле доступно по тому же имени, что и event.) Функции add/remove, составляющие event, *вызываются* соответственно как += и -=. Никаких операций +/-, разумеется, нету.
📎 Подробнее
@csharp_ci