На недавней встрече комитет C++ активно взялся за C++26. Уже есть первые новинки, которые нас будут ждать в готовящемся стандарте C++:
static_assert,_,std::to_string,native_handle(),*function*,constexpr,std::submdspan,Строки в dotnet являются предназначенной только для чтения последовательностью Char-ов. Об этом явно написано в документации MicrosoftЧитать полностью »
Отображение текстовой информации — наверное, самая базовая и важная часть многих Android-приложений. В данной статье пойдет речь о TextView. Каждый разработчик, начиная с «Hello World», постоянно сталкивается с этим элементом пользовательского интерфейса. Периодически в работе с текстом приходится задумываться о реализации различных дизайнерских решений или улучшении производительности при отрисовке экрана.
Я расскажу об устройстве TextView и некоторых тонкостях работы с ним. Основные советы были взяты из докладов прошедших Google I/O.
![[DotNetBook]: Span, Memory и ReadOnlyMemory - 1](https://www.pvsm.ru/images/2018/08/13/DotNetBook-Span-Memory-i-ReadOnlyMemory.jpeg "[DotNetBook]: Span, Memory и ReadOnlyMemory - 1")
Этой статьей я продолжаю публиковать целую серию статей, результатом которой будет книга по работе .NET CLR, и .NET в целом. За ссылками — добро пожаловать по кат.
Визуальных отличий Memory<T> от Span<T> два. Первое — тип Memory<T> не содержит ограничения ref в заголовке типа. Т.е., другими словами, тип Memory<T> имеет право находиться не только на стеке, являясь либо локальной переменной либо параметром метода либо его возвращаемым значением, но и находиться в куче, ссылаясь оттуда на некоторые данные в памяти. Однако эта маленькая разница создает огромную разницу в поведении и возможностях Memory<T> в сравнении с Span<T>. В отличии от Span<T>, который представляет собой средство пользования неким буфером данных для некоторых методов, тип Memory<T> предназначен для хранения информации о буфере, а не для работы с ним.
Эта статья — вторая из цикла про Span<T> и Memory<T>. Она является вводной для Memory<T> в том плане что здесь я решил расписать общую терминилогию, а вот примеры совместного использования — решил вывести в отдельную статью
- Span<T>: новый тип данных .NET
- Span<T> и ReadOnlyMemory<T>
- Практика использования Span<T> и Memory<T>
![[DotNetBook] Span: новый тип данных .NET - 1](https://www.pvsm.ru/images/2018/08/01/DotNetBook-Span-novyi-tip-dannyh-NET.jpeg "[DotNetBook] Span: новый тип данных .NET - 1")
С этой статьей я продолжаю публиковать целую серию статей, результатом которой будет книга по работе .NET CLR, и .NET в целом (уже готово около 200 страниц книги, так что добро пожаловать в конец статьи за ссылками).
Как язык, так и платформа существуют уже много лет: и все это время существовало множество средств для работы с неуправляемым кодом. Так почему же сейчас выходит очередной API для работы с неуправляемым кодом если по сути он существовал уже много-много лет? Для того чтобы ответить на этот вопрос достаточно понять чего не хватало нам раньше.
Разработчики платформы и раньше пытались нам помочь скрасить будни разработки с использованием неуправляемых ресурсов: это и автоматические врапперы для импортируемых методов. И маршаллинг, который в большинстве случаев работатет автоматически. Это также инструкция stackallloc, о которой говорится в главе про стек потока. Однако, как по мне если ранние разработчики с использованием языка C# приходили из мира C++ (как сделал это и я), то сейчас они приходят из более высокоуровневых языков (я, например, знаю разработчика, который пришел из JavaScript). А что это означает? Это означает что люди со все большим подозрением начинают относиться к неуправляемым ресурсам и конструкциям, близким по духу к C/C++ и уж тем более — к языку Ассемблера.
Статья хоть и большая, но является вводной в тему
Span<T>иMemory<T>. Планируется что выйдет еще две: первая проMemory<T>, MemoryManager<T>, MemoryHandler<T>иMemoryPool<T>. Вторая — про низкоуровневые особенности и вопросы кSpan<T>иMemory<T>.