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

Сегодня в программе:

• auto
• nullptr
• range-based циклы
• override и final
• строго-типизированный enum
• интеллектуальные указатели
• лямбды
• non-member begin() и end()
• static_assert и классы свойств
• семантика перемещения

Android Studio — очень надежный инструмент. Он имеет самый простой и вместе с тем самый гибкий интерфейс для разработки пользовательского интерфейса для всех типов устройств.
Мы можем перетаскивать элементы представления и виджеты в нашем редакторе макетов и детально настраивать через несколько строк в xml.

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

Но иногда хочется, чтобы этот инструмент делал нас еще более продуктивными.

Введение

«В моё время игры были лучше. Они были интереснее, потому что геймплей считался более важным, чем графика».

— Геймеры, рождённые в любом десятилетии

Каким бы ни было «ваше время», думаю, вы в какой-то степени согласны с этим мнением. Для меня это был период с середины 80-х до середины 90-х, когда я проводил бесчисленные часы за Sir Fred, Atic Atac, Airborne Ranger, Monkey Island, Twilight: 2000, Stunts, Gunship 2000, Twinsen’s Adventure, Dark Sun, Challenge for Ancient Empires, серией the X-Wing и очень многими другими играми.

Иногда мы испытываем приступы ностальгии и нам хочется сыграть в одну из тех игр снова. В этом случае у нас есть на выбор несколько вариантов.

Сыграть в remastered-версию. Некоторые игры настолько потрясающи и собрали настолько преданную базу фанатов, что выпускается официальное «новое издание». Это точно такая же игра, но с современной графикой. Отличным примером таких игр может быть замечательная Monkey Island Special Edition.

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

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

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

К сожалению, эта простота имеет свою цену: низкую производительность. Несмотря на то, что существует множество способов оптимизации и параллелизации трассировщиков лучей, они всё равно остаются слишком затратными с точки зрения вычислений для выполнения в реальном времени; и хотя оборудование продолжает развиваться и становится быстрее с каждым годом, в некоторых областях применения необходимы красивые, но в сотни раз быстрее создаваемые изображения уже сегодня. Из всех этих областей применения самыми требовательными являются игры: мы ожидаем рендеринга отличной картинки с частотой не менее 60 кадров в секунду. Трассировщики лучей просто с этим не справятся.

Тогда как это удаётся играм?

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

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

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

«Конечным результатом» этой работы будут два завершённых, полностью рабочих рендереров: трассировщик лучей и растеризатор. Хотя в них используются очень отличающиеся подходы, при рендеринге простой сцены они дают схожие результаты:

Добрый вечер, хаброчитатели!

В предыдущих статьях (один, два) мы определили понятие символьного устройства и написали простейший пример символьного драйвера. Последняя часть посвещена проверки его работоспособности. На Хабре уже есть примеры как можно протестировать драйвер, например: тык.

Я попытаюсь рассмотреть данный вопрос чуть подробнее, надеюсь, вам понравится.

Привет хаброчитателям!

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

В данной статье мы добавим в наш драйвер функции открытия scull_open, чтения/записи scull_read/scull_write и получим первый рабочий драйвер устройства.



Хочу выразить благодарность всем пользователям, которые прочитали, лайкнули и прокомментировали мою предыдущую статью. Отдельное спасибо за уточнения Kolyuchkin и dlinyj.



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

Сразу к делу!

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

Цель данной статьи — показать принцип реализации драйверов устройств в системе Linux, на примере простого символьного драйвера.

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

Это моя первая статья, пожалуйста не судите строго!

P.S

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

Часть 1 — Введение, инициализация и очистка модуля ядра.
Часть 2 — Функции open, read, write и trim.
Часть 3 — Пишем Makefile и тестируем устройство.

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

Итак, начнем.

В этой статье я покажу, как написать рудиментарный, нативный x86-64 just-in-time компилятор (JIT) на CPython, используя только встроенные модули.

Код предназначен для UNIX-систем, таких как macOS и Linux, но его должно быть легко транслировать на другие системы, типа Windows. Весь код опубликован на github.com/cslarsen/minijit.

Цель — сгенерировать в рантайме новые версии нижеприведённого ассемблерного кода и выполнить их.

48 b8 ed ef be ad de  movabs $0xdeadbeefed, %rax
00 00 00
48 0f af c7           imul   %rdi,%rax
c3                    retq

В основном, мы будем иметь дело с левой частью кода — байтовой последовательностью 48 b8 ed ... и так далее. Эти 15 байтов в машинном коде составляют функцию x86-64, которая умножает свой аргумент на константу 0xdeadbeefed. На этапе JIT будут созданы функции с разными такими константами. Такая надуманная форма специализации должна продемонстрировать базовую механику JIT-компиляции.

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

Например, iPad 2 — всего в нем 512 Мб RAM. Однако приложению доступно только примерно 275 Мб. Когда занимаемая приложением память будет приближаться к этой границе, операционная система пришлет так называемое «Memory warning» — мягко, но настойчиво предложит освободить память. И если лимит все же будет превышен, операционная система остановит приложение. Пользователь будет думать, что ваша игра упала и побежит писать гневное письмо в саппорт.



Главный потребитель памяти — это, конечно, графика. В этой статье мы попробуем рассказать о пусть немного сложном, но эффективном способе, который используется для уменьшения занимаемой текстурами памяти, а также для повышения скорости отрисовки.

Это не очередная статья про Dagger и его возможности. Не будет ни слова про другие DI фреймворки.


Цель данной публикации — продемонстрировать подход к получению зависимостей во фрагментах, диалогах и активити.

Привет, Хабр! Культурные воины продолжаются, люди сражаются по разные стороны баррикад, пытаясь решить: tabs or spaces. На эту же тему мы нашли интересную статью Скотта Хансельмана, в которой он рассказывает про инструмент, решающий это спор, EditorConfig в Visual Studio. Всех интересующихся прошу под кат.

В лингвистике существует такое понятие, как интерференция — влияние родного языка на тот, который мы изучаем. Чаще всего это попытки найти какие-то общие черты в фонетике, грамматике и лексике в родном и иностранном языках.

На начальном этапе это помогает разобраться в фонетике, но потом приходится свыкаться с большим количеством правил и исключений, которые не имеют аналогов в русском.
Мы попросили одного из самых опытных носителей английского языка в нашей школе, Трессу, рассказать о наиболее частых ошибках ее русскоязычных студентов и как их исправить. Но прежде чем перейти к самому списку, есть ряд советов от нее, чтобы количество ошибок постоянно уменьшалось:

В свободное и не свободное время[1] я развиваю несколько своих проектов на github, а также, по мере сил, участвую в жизни интересных для меня, как программиста, проектах.

Недавно один из коллег попросил консультацию: как выложить разработанную им библиотеку на github. Библиотека никак не связана с бизнес-логикой приложения компании, по сути это адаптер к некоему API, реализующему определённый стандарт. Помогая ему, я понял что вещи, интуитивно понятные и давно очевидные для меня, в этой области, совершенно неизвестны человеку делающему это впервые и далёкому от Open Source.

Я провел небольшое исследование и обнаружил что большинство публикаций по этой теме на habrahabr освещают тему участия (contributing), либо просто мотивируют каким-нибудь образом примкнуть к Open Source, но не дают исчерпывающей инструкции как правильно оформить свой проект. В целом в рунете, если верить Яндекс, тема освещена со стороны мотивации, этикета контрибуции и основ пользования github. Но не с точки зрения конкретных шагов, которые следует предпринять.

Так что из себя представляет стильный, модный, молодёжный Open Source проект в 201* году?

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

Поскольку я создаю обучающие видео ролики о линуксе, мне удобнее работать именно на нём. Но монтировать хочется попробовать в «финальном вырезе». Уж очень мне приглянулась идея магнитной ленты времени.



Так вот, задача стоит такая: нужен раздел на системном накопителе, причём с такой файловой системой, которая поддерживается на чтение и запись всеми перечисленными операционками. На этом разделе будут храниться скачанные из интернета файлы и меж-операционные проекты.

В этой статье рассматривается проектирование типов для работы с объектами линейной алгебры: векторами, матрицами, кватернионами. Показано классическое применение механизма перегрузки стандартных операций, использование приёма «Copy On Write» и аннотаций.

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

Распространенные ошибки

1. Самая большая ошибка при чтении статьи на английском — это частое заглядывание в словарь.
2. Использование переводных словарей там, где можно было воспользоваться толковым (англо-английским) словарем.
3. Попытка сразу вникнуть во все детали текста.
4. Чтение слишком сложных статей с уровнем знания английского Beginner или Elementary.

Эта статья также есть на английском.

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

Командная строка для администратора или пользователя — это не только инструмент, которым можно сделать все, но и инструмент, который кастомизируется под себя любимого бесконечно долго. Недавно пробегал перевод на тему удобных приемов в CLI. Но у меня сложилось впечатление, что сам переводчик мало пользовался советами, из-за чего важные нюансы могли быть упущены.

Под катом — дюжина приемов в командной строке — из личного опыта.

Пара слов от переводчика

Продолжая освещать тему std::system_error в рунете, я решил перевести несколько статей из блога Andrzej Krzemieński, который мне посоветовали в комментариях к предыдущему посту.

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

Так же хочу предупредить, что у Andrzej Krzemieński достаточно сумбурный стиль изложения, который я не стал править. Все же я выступаю в роли переводчика, а не редактора. Так что, возможно, чтобы понять некоторые тезисы придется перечитать дважды.

Продолжение цикла обзорных статей с конференции CppCon 2017.

На этот раз очень интересное выступление от автора Compiler Explorer (godbolt.org). Обязательно читать всем, кто для быстроты умножает на 2 с помощью сдвига (по крайней мере, на x86-64). Если вы знакомы с ассемблером x86-64, то можете перемотать до разделов с примерами ("Умножение", "Деление" и т.д). Далее слова автора. Мои комментарии в квадратных скобках курсивом.

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