Здравствуйте, коллеги.

В рамках проработки темы С++20 нам в свое время попалась уже довольно старенькая (сентябрь 2018) статья из хаброблога «Яндекса», которая называется "Готовимся к С++20. Coroutines TS на реальном примере". Заканчивается она следующей весьма выразительной голосовалкой:



«Почему бы и нет», — решили мы и перевели статью Давида Пиларски (Dawid Pilarski) под названием «Coroutines introduction». Статья вышла чуть более года назад, но, надеемся, все равно покажется вам очень интересной.

Цель — показать, где TS дает иллюзию безопасности позволяя получить ошибки во время работы программы.

Мы не будем говорить о багах, в TS их достаточно
1,500 open bugs and 6,000 closed (‘is:issue is:open label:Bug’)

Все примеры будет рассмотрены при:

• TS strict mode включен (написал статью пока разбирался)
• Без явных «any»: «as any», «Objects», «Function», {[key: string]: unknown}
• Без неявных «any»: (noImplicitAny): не типизированные импорты (pure JS files), неправильный вывод типов
• Без ложных догадок о типах: ответ от сервера, типизация сторонних библиотек

Содержание:

• Введение
• Nominal types, custom types — когда вещи кажутся одинаковым, но такие разные
• Type variance, exact types — об отношении между типами
• Refinement invalidation — поговорим о доверии
• Exceptions — стоит ли признаваться, когда накосячил?
• Unsafe operations — уверенность не всегда идет на пользу
• Бонусные случаи — проверка типов на этапе PR ревью
• Заключение

В предыдущей статье мы обсуждали, почему функциональное программирование это совсем не то, что распиарено, и что оно совершенно не противоречит ООП, так, что даже сам "Дядя Боб" пишет про хороший ФП дизайн порождающий хороший ООП дизайн программы (и наоборот).

Сейчас же я хочу рассказать, что такое монады на самом деле, чем они полезны для обычного практикующего разработчика, и приведу примеры, почему недостаточная поддержка их в распространенных языках приводит к копипасте и ненадежным решениям.

Но ведь в интернете буквально сотни статей про ФП и монады, зачем писать еще одну?

Дело в том, что все их (по крайней мере те что я читал) можно поделить условно на две категории: с одной стороны это статьи где вам объяснят что монада это моноид в категории эндофункторов, и что если монада T над неким топосом имеет правый сопряжённый, то категория T-алгебр над этой монадой — топос. На другой стороне располагаются статьи, где вам рассказывают, что монады — это коробки, в которых живут собачки, кошечки, и вот они из одних коробок перепрыгивают в другие, размножаются, исчезают… В итоге за горой аналогий понять что-то содержательное решительно невозможно.

Получается, что первые обычно полезны тем, кто и так знает обсуждаемую тему, а вторые даже не знаю на кого рассчитаны: сколько я их не прочитал, ничего полезного понять из них мне не удалось.

Я же хотел бы занять промежуточную позицию, и рассказать про монады без заумных терминов, но и без котиков, используя понятные ООП разработчикам термины: интерфейсы, паттерны, копипаста, инкапсуляция сложности, бойлерплейт, и так далее. В процессе работы над статьёй ни один термин теории категории использован не был.

В серии про надежное программирование [1], [2] остался незаслуженно забытым Swift. Я, честно говоря, просто не считал его кроссплатформенным, а работающим исключительно для macOS/iOS. Тут случайно выяснилось, что Swift также поддерживается такой средой разработки, как RemObjects Elements.

Оказалось, у неё Универсальный Компилятор. Умеет компилировать программы на C#, Go, Java, Oxygene Object Pascal, Swift для: Android, Cocoa (MacOS, iOS, tvOS), JVM, Linux (x64, armv6, aarch64), .NET/.NET Core/Mono, Native Windows(x86/x64), WebAssembly.

Причем делает это практически в любых комбинациях язык → целевая система! Например, можно написать программу на Java, которая будет использовать WPF для целевой платформы .NET, и это все есть в примерах, идущих в поставке.

Итак, представляю мини-заметку про RemObjects Elements, а заодно про надежность двух поддерживаемых в ней языков — Swift и Oxygene.

Рисунок с сайта radionetplus

На днях в Праге прошла встреча международного комитета по стандартизации C++. И-и-и-и…



C++20 готов! Осталось поставить штампик от ISO, но это чисто формальный шаг, с которым не должно быть проблем.

Поздравляю всех с этим замечательным событием! Concepts, Coroutines, Modules, Ranges, std::format, constexpr new и constexpr алгоритмы+vector+string, datetime, jthread, span, bit_cast и многие другие мелкие и большие нововведения.

Что успели добавить и поправить в последний момент, что предложили разломать и что все хотят видеть в C++23 — обо всём этом под катом.

В преддверии старта курса «Разработчик C#» подготовили перевод интересного материала.

---

Async/Await — Введение

Языковая конструкция Async/Await существует со времен C# версии 5.0 (2012) и быстро стала одним из столпов современного программирования на .NET — любой уважающий себя C# разработчик, должен использовать ее для повышения производительности приложений, общей отзывчивости и разборчивости кода.

Async/Await делает обманчиво простым внедрение асинхронного кода и избавляет программиста от необходимости разбираться в деталях его обработки, но многие ли из нас действительно знают, как она работает, и каковы преимущества и недостатки этого метода? Существует много полезной информации, но она разобщена, поэтому я решил написать эту статью.

Ну что ж, давайте углубимся в тему.

Каждый проект требует жертвы. Главное, чтобы не слишком большой. Команда Mail.Ru Cloud Solutions перевела статью Алекса Стейвли про минусы технического долга и его способность уничтожить даже самый успешный проект. Предупреждение автора: в этой статье не так много практики, как хотелось бы, но она может натолкнуть на размышления.

Вступление коротко: хочу рассказать про онлайн плеер Ютюб для Андроида с локальными плейлистами, каналами и рекомендациями.

Вступление развернутое

Некоторое время назад я столкнулся ровно с такой проблемой, как и автор замечательного приложения Channel Whitelist, и определил для себя к ней ровно такое же отношение: я хочу иметь возможность время от времени давать ребенку планшет или смартфон с мультиками, но меня совершенно не устраивает, куда через 2-3 клика заводит ребенка список рекомендаций в стандартных приложениях — клиентах Ютюб.

К сожалению, после установки приложения Channel Whitelist уже у него был обнаружен другой более прозаичный, но всё равно фатальный недостаток — NIH мне (и, главное, сыну) показался не очень удобным его интерфейс, особенно после привычки использовать плеер YouTube Kids.

В общем, еще через некоторое время я созрел, чтобы сделать свою реализацию. Еще через некоторое время стало возможным поставить тег на первый релиз.

Основные возможности:

• Добавляйте любимые каналы и плейлисты — они будут сохранены и проиндексированы в локальной базе
• Внутри добавленных плейлистов выключайте лишние ролики, если они вам не нужны
• Список рекомендаций генерируется случайно только из добавленных в приложение каналов и плейлистов

Исходники открыты, лицензия GPLv3: https://github.com/sadr0b0t/yashlang/

Дальше обзор основных возможностей более подробно, плюс немного технических подробностей о том, как играть видео с Ютюб в вашем приложении на Андроид без использования АПИ Гугл и веб-оберток.

В WinAPI есть функция CreateRemoteThread, позволяющая запустить новый поток в адресном пространстве другого процесса. Её можно использовать для разнообразных DLL-инъекций как с нехорошими целями (читы в играх, кража паролей, и т. д.), так и для того, чтобы на лету исправить баг в работающей программе, или добавить плагины туда, где они не были предусмотрены.

В целом эта функция обладает сомнительной прикладной полезностью, поэтому не удивительно, что в Linux готового аналога CreateRemoteThread нет. Однако, мне было интересно, как он может быть реализован. Изучение темы вылилось в неплохое приключение.

Я подробно расскажу о том, как с помощью спецификации ELF, некоторого знания архитектуры x86_64 и системных вызовов Linux написать свой маленький кусочек отладчика, способный загрузить и исполнить произвольный код в уже запущенном и работающем процессе.

Для понимания текста потребуются базовые знания о системном программировании под Linux: язык Си, написание и отладка программ на нём, осознание роли машинного кода и памяти в работе компьютера, понятие системных вызовов, знакомство с основными библиотеками, навык чтения документации.

Письменность майя была единственной полноценной системой письменности в Америке, но благодаря стараниям отважных испанских конкистадоров к XVII веку она была полностью забыта. Тем не менее, тысячи этих символов сохранились на резных камнях, фресках и керамике, и в XX веке обычный советский аспирант выдвинул идею, которая позволила их расшифровать. И данная статья покажет, как устроена эта система.

Когда я впервые увидел слово never, то подумал, насколько бесполезный тип появился в TypeScript. Со временем, все глубже погружаясь в ts, стал понимать, какой мощью обладает это слово. А эта мощь рождается из реальных примеров использования, которыми я намерен поделиться с читателем. Кому интересно, добро пожаловать под кат.

Общеизвестно, что семантика инициализации — одна из наиболее сложных частей C++. Существует множество видов инициализации, описываемых разным синтаксисом, и все они взаимодействуют сложным и вызывающим вопросы способом. C++11 принес концепцию «универсальной инициализации». К сожалению, она привнесла еще более сложные правила, и в свою очередь, их перекрыли в C++14, C++17 и снова поменяют в C++20.

Под катом — видео и перевод доклада Тимура Домлера (Timur Doumler) с конференции C++ Russia. Тимур вначале подводит исторические итоги эволюции инициализации в С++, дает системный обзор текущего варианта правила инициализации, типичных проблем и сюрпризов, объясняет, как использовать все эти правила эффективно, и, наконец, рассказывает о свежих предложениях в стандарт, которые могут сделать семантику инициализации C++20 немного более удобной. Далее повествование — от его лица.

Здравствуй, читатель. В этой статье описаны атрибуты со всех сторон — начиная от спецификации, смысла и определения атрибутов, создания собственных и работе с ними, заканчивая добавлением атрибутов на рантайме и наиболее полезными и интересными существующими атрибутами. Если вам интересна тема атрибутов в C#, то добро пожаловать под кат.

Платформа .NET предоставляет множество готовых примитивов синхронизации и потокобезопасных коллекций. Если при разработке приложения нужно реализовать, например, потокобезопасный кэш или очередь запросов — обычно используются эти готовые решения, иногда сразу несколько. В отдельных случаях это приводит к проблемам с производительностью: долгим ожиданием на блокировках, избыточному потреблению памяти и долгим сборкам мусора.

Эти проблемы можно решить, если учесть, что стандартные решения сделаны достаточно общими — они могут иметь избыточный в наших сценариях оверхед. Соответственно, можно написать, например, собственную эффективную потокобезопасную коллекцию для конкретного случая.

Под катом — видео и расшифровка моего доклада с конференции DotNext, где я разбираю несколько примеров, когда использование средств из стандартной библиотеки .NET (Task.Delay, SemaphoreSlim, ConcurrentDictionary) привело к просадкам производительности, и предлагаю решения, заточенные под конкретные задачи и лишённые этих недостатков.

В своей практике я часто встречаю, в различном окружении, код вроде того, что приведен ниже:

[1] var x = FooWithResultAsync(/*...*/).Result;

//или
[2] FooAsync(/*...*/).Wait();

//или
[3] FooAsync(/*...*/).GetAwaiter().GetResult();

//или
[4] FooAsync(/*...*/)
    .ConfigureAwait(false)
    .GetAwaiter()
    .GetResult();

//или
[5] await FooAsync(/*...*/).ConfigureAwait(false)

//или просто
[6] await FooAsync(/*...*/)

Из общения с авторами таких строк, стало ясно, что все они делятся на три группы:

• Первая группа, это те, кому ничего не известно о возможных проблемах с вызовом Result/Wait/GetResult. Примеры (1-3) и, иногда, (6), типичны для программистов из этой группы;
• Ко второй группе относятся программисты, которым известно о возможных проблемах, но они не знают причин их возникновения. Разработчики из этой группы, с одной стороны, стараются избегать строк вроде (1-3 и 6), но, с другой, злоупотребляют кодом вроде (4-5);
• Третья группа, по моему опыту самая малочисленная, это те программисты, которые знают о том, как код (1-6) работает, и, поэтому, могут сделать осознанный выбор.

Возможен ли риск, и на сколько он велик, при использовании кода, как в приведенных выше примерах, зависит, как я отмечал ранее, от окружения.

Вам нужна недорогая «печатная машинка», но вместо нее Microsoft и Acer сделали для вас «китайскую поделку» с заведомо неработоспособной конфигурацией.



Под катом о том, как выглядит работа системы с бюджетным процессором, Windows 10 и накопителем в 32 ГБ.

Стандарт C++17 добавил в язык новую фичу: Class Template Argument Deduction (CTAD). Вместе с новыми возможностями в C++ традиционно добавились и новые способы отстрела собственных конечностей. В этой статье мы будем разбираться, что из себя представляет CTAD, для чего используется, как упрощает жизнь, и какие в нём есть подводные камни.

Хабровчане, всех с пятницей! Сейчас у подавляющего большинства читателей хабра рабочий день уже закончился, поэтому можно расслабиться и немного отвлечься от серьезных тем. Вы знали, что на css можно каламбурить? На кдпв один из примеров, а под катом небольшая простыня специфических css шуток.

Практически все нетривиальные программы выделяют и используют динамическую память. Делать это корректно становится все более важным, поскольку программы становятся все более сложными, а ошибки еще более дорогостоящими.

Типичными проблемами являются:

1. утечки памяти (не освобождение более не используемой памяти)
2. двойное освобождение (высвобождение памяти более одного раза)
3. использование после освобождения (использование указателя на память, ранее уже освобождённую)

Задача заключается в том, чтобы отслеживать указатели, ответственные за освобождение памяти (т.е.владеющие памятью), и отличать указатели, которые просто указывают на участок памяти, контролировать где они находятся, и которые из них активны (в области видимости).

Проблема памяти может возникнуть, когда в процессе выполнения программы нужно иметь большое количество объектов, особенно если есть ограничения на общий размер доступной оперативной памяти.

Ниже приводится обзор некоторых методов уменьшения размера объектов, которые позволяют существенно сократить объем оперативной памяти, необходимой для программ на чистом Python.