Каждая новая спецификация OpenMP вводит очень полезные и необходимые дополнения к уже существующему функционалу. Например, в версии 3.0 были добавлены так ожидаемые задачи (tasks), позволившие решать ещё больший спектр задач по распараллеливанию приложений. В 3.1 целый ряд улучшений по работе с задачами и редукциями.

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

Начнем знакомство непосредственно с использованием технологии OpenMP и рассмотрим в этой заметке некоторые базовые конструкции.

Несколько новых возможностей C++17 позволяют написать более компактный и ясный код. Это особенно важно при шаблонном мета-программировании, результат которого часто выглядит жутко…

Например если вы хотите выразить if, который вычисляется во время компиляции, вы будете вынуждены написать код используя приём SFINAE (например enable_if) или статическую диспетчеризацию (tag dispatching). Такие выражения тяжело понять, и они выглядят как магия для разработчиков, незнакомых с продвинутыми шаблонами мета-программирования.

К счастью, с появлением C++17 мы получаем if constexpr. Теперь большинство приёмов SFINAE и статической диспетчеризации отпадает, и код уменьшается, становится похожим на "обычный" if.

Эта статься демонстрирует несколько приёмов использования if constexpr.

В GCC7 реализован последний стандарт С++17 (будет принят в этом году). Хотелось бы обратить внимание, что изменились правила вывода типа auto при фигурной инициализации.

Язык C++ постоянно развивается, и нам как разработчикам статического анализатора важно следить за всеми изменениями, чтобы поддерживать все новые возможности языка. В этой обзорной статье я хотел бы поделиться с читателем наиболее интересными нововведениями, появившимися в C++17, а также продемонстрировать их на примерах.

Приветствую всех, кому стало интересно узнать о моем небольшом проекте, которым занимаюсь в свободное от работы время, о своем долгоиграющем проекте под названием «tengine».

Какова же цель этого поста? Ответ простой — я ищу однодумцев. Я верю в то, что есть еще много людей, которым нравится славный и добрый олдскул. В этом и вся миссия — писать удовольствия ради что-то маленькое, но вполне функциональное, платформу для «приставочных» игрушек в стиле 8/16 бит.

tengine DEMO game (web version) управление: клавиши со стрелкам, ctrl. Полноценная концовка.

Главная особенность, отличающая tengine от сотен подобных поделок — не совсем стандартная идеология:

• архитектура проекта делает упор на минимизацию использования динамической памяти. Если память и выделяется, она выделяется исключительно на инициализации подсистем
• использовать динамическую память нужно так, как будто не существует операционной системы, постоянно помнить о фрагментации. Удаление памяти происходит в строго обратном порядке создания (за этим следит простой механизм контроля удаляемых указателей)
• использование сторонних библиотек сведено к минимуму и должно быть аргументировано, зачастую это потенциальный источник фрагментации памяти
• игровая сцена представляет собою готовую для использования память, сгенерированная редактором уровней
• работа с объектами сцены игры ведется исключительно через идентификаторы, динамически создать объект невозможно
• использование fixed point вместо float
• мультиплатформенность
• официальный язык проекта — си

Я долгое время был разработчиком систем для десктопа. Сначала это был WinForms, потом более мощный и гибкий WPF. С тех пор прошло много времени и курсирует множество слухов и мнений о том, что WPF завершает свою жизнь, ведь сейчас столько разговоров о том, что можно писать настольные приложения на JS. А еще Microsoft усиленно двигает в массы платформу WinRT для разработки новых приложений. Это не могло меня и коллег оставить равнодушным.

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



Существует мнение, что развитие десктопной разработки остановилось в своем развитии и для этого есть несколько предпосылок. Одна из них – остановка, или даже лучше сказать стагнация, в самой базе, в визуальном фреймворке WPF. Значительных обновлений для него не было вот уже лет 5, как может показаться. Официальный тулкит давно не обновлялся, точнее с февраля 2010 года, т.е. вот как раз те самые 5 лет. При этом компании, специализирующиеся на кастом-компонентах, как например DevExpress и Telerik успешно выпускают обновления и составляют планы на будущее относительно WPF. Даже если вы ориентированы на новинки, то компоненты для WinRT все равно используют концепции и общую структуру XAML, который никуда не уходит.
Далее мы хотим представить причины, по которым WPF некоторые считают неактуальным, и опровержение этих причин.

Нововведения в WPF 4

WPF (Windows Presentation Foundation) — один из компонентов ядра .NET Framework, который позволяет разработчикам создавать богатые, различные Windows приложения. WPF 4 содержит важные улучшения в продуктивности, производительности, возможностей — в частности в областях: элементов управления, XAML, текста, графики, интеграции в Windows 7 (мультитач, интеграция в панель задач, и т.п.), основных принципов работы, развертывания. Это только первая статья из серии, которая описывает нововведения.

Я напишу отдельную статью, которая опишет важные изменения, которые грядут в WPF и Silverlight конструкторах в VS 2010.