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

Метапрограммирование становится столь же неотъемлемой частью написания кода на C++, как и использование стандартной библиотеки, часть которой создана именно для использования на этапе компиляции. Сегодня мы произведем на свет библиотеку безопасного приведения скалярных типов C++, метапрограммируя шаблонами!

Существует довольно много приложений под Android, которые совмещают C++ и Java код. Где Java выступает оберткой/прослойкой, а C++ выполняет всю грязную работу. Пожалуй, ярким примером могут служить игры. В связи с этим часто приходится вызывать Java код из нативного для доступа к системным свойствам и плюшкам, которые предоставляет система (переключится на другую активность, послать или скачать что-либо из интернета). Причин много, а проблема одна: каждый раз приходится писать в лучшем случае 5 строчек кода и помнить, какую сигнатуру функции нужно запихнуть в параметр. Потом еще нужно перевести эти параметры в нужный тип. Стандартный пример из туториалов:

long f (int n, String s, float g); 

Строка-сигнатура для данного метода будет (ILjava/lang/String;F)J.

Вам удобно это все запоминать? А переводить С-строки в jstring? Мне — нет. Мне хочется писать:

CallStaticMethod<long>(className, “f”, 1, 1.2f); 

Добрый день, хабрасообщество. Мне хотелось бы продолжить рассмотрение аспектов реализации DICOM Viewer'а, и сегодня речь пойдёт о функциональных возможностях.


Итак, поехали.

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

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

Метапрограммирование реализовано в той или иной мере в очень разных языках; если не рассматривать экзотические и близкие к ним языки, то самым известным примером метапрограммирования является С++ с его системой шаблонов. Из «новых» языков можно рассмотреть D и Nim. Одна из самых удачных попыток реализации метапрограммирования — язык Nemerle. Собственно, на примере этой четверки мы и рассмотрим сабж.

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

Доброго здравия! Не удивлюсь, что Вы раньше даже не слышали об этой программе. Как и я, до того дня, когда мне пригодился Python Debugger. Да, знаю, есть pdb, но его функционал и то, как он представлен, мне совершенно не приглянулось. После непродолжительных поисков я наткнулся на этот замечательный продукт. Тут есть все, что может пригодиться в отладке ваших Python приложений (скажу сразу: данный язык я не изучал, поэтому, если какие-то неточности всплывут, просьба не ругаться).

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

64-битные ошибки достаточно тяжело обнаружить, так как они сродни бомбе замедленного действия: могут дать о себе знать далеко не сразу. Статический анализатор PVS-Studio облегчает задачу поиска и исправления подобных ошибок. Однако в этом направлении были сделаны ещё несколько шагов: недавно были более внимательно пересмотрены 64-битные диагностики, вследствие чего их распределение по уровням важности изменилось. Речь в данной статье пойдёт об этих изменениях, а также о том, как это повлияло на работу с инструментом и на поиск ошибок. Примеры 64-битных ошибок из реальных приложений прилагаются.

О чём статья?

Для начала хотелось бы внести конкретики по содержанию. В статье раскрываются следующие темы:

1. Изменения в анализаторе PVS-Studio, затрагивающие поиск 64-битных ошибок;
2. Обзор 64-битных ошибок первого уровня, найденных анализатором PVS-Studio, и краткие комментарии к ним;
3. Сравнение эффективности в поиске наиболее важных ошибок средствами PVS-Studio и Microsoft Visual Studio 2013.

Первый пункт говорит сам за себя: в нём будут рассмотрены основные изменения PVS-Studio, касающиеся анализа 64-битных ошибок, а также то, как они отразятся на работе с инструментом.

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

В третьем разделе осуществляется сравнение в эффективности поиска этих ошибок статическим анализатором PVS-Studio и средствами среды Microsoft Visual Studio 2013. Причём, в случае Visual Studio, для поиска ошибок использовались как компилятор, так и статический анализатор.

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

Предисловие

Надеюсь, всем, кто использовал в разработке Qt, было интересно узнать, как же устроена метаинформация и что же происходит внутри этого прекрасного фреймворка? Об этом и будет эта запись — мы заглянем внутрь исходников и попробуем написать реализацию динамического метаобъекта (но не в этой записи). Метаобъекта, в котором можно создавать сигнали и слоты в realtime.

Фреймворк Qt предоставляет неплохие средства разработки — входящая в него IDE Qt Creator включает дизайнер, отладчик, профайлер и другие удобные вещи. К сожалению, даже со всем этим иногда не очень понятно, почему приложение в данные момент выглядит так, как выглядит: чего-то не видно, что-то выглядит не так, как ожидалось, где-то неподходящий размер шрифта или неверная картинка.

Часть этих проблем может быть решена в Qt Designer, но только часть. Qt Designer имеет несколько существенных недостатков: во-первых, он неверно отображает положение Qt Quick компонентов в случае активного использования Javascript при расчете их координат и размеров, во-вторых в дизайнере мы видим состояние только «пустой» формы, без загруженных в неё данных. В общем, очень не хватает чего-то вроде инструментов разработчика в любом современном браузере: чтобы можно было посмотреть всё дерево компонентов, найти нужный, увидеть его положение относительно других, свойства, поправить на лету что-то, подобрать цвет\шрифт\размер, увидеть какие обработчики повешены на события и т.д.

И такой инструмент в мире Qt появился! Встречайте — GammaRay, средство интроспекции приложений на Qt. GammaRay понимает, что такое Qt, из чего состоит ваше Qt-приложение, как в нём взаимодействую компоненты, как они выглядят, как генерируются и обрабатываются события и т.д. Давайте посмотрим, что умеет GammaRay.

Говоря о тексте, большинство программистов C++ думают о массивах кодов символов и кодировке, которой эти коды соответствуют. Наиболее опытные разработчики вообще не мыслят понятие текста без указания кодировки, наименее опытные просто считают массив байтов с кодами символов данностью и интерпретируют в понятиях кодировки операционной системы. Фундаментальная разница между этими двумя подходами не только в опыте разработчика, но и в том, что не думать о кодировке намного проще. Пора рассмотреть способ, как не заботиться о хранении кодировки, перекодировке текста, получать свободный доступ к символам и при этом видеть безошибочное представление текста вне зависимости от того, кто и где смотрит на строку текста: в Китае ли, в США или на острове Мадагаскар.

Создавая объект за объектом, мы часто не обращаем внимания на такую «мелочь», как динамическое выделение памяти. Наравне с копированием и сериализацией, выделение памяти из кучи через new постепенно сводит на нет преимущества C++ в скорости. Чем интенсивнее мы пользуемся заветным new, тем сложнее становится приложению, поскольку память кончается, фрагментируется и всячески стремится утекать. Эта участь уже постигла удобные, но неявно опасные для производительности контейнеры STL: vector, string, deque, map. Особенно обидно терять скорость на выделении небольших объектов в больших количествах. Но есть способ обработать размещение памяти таких объектов на стеке, при этом скрывая детали реализации в специальный класс данных. В этом нам поможет механизм размещающего new — непревзойденный способ оптимизации приложения, полного частых и мелких выделений памяти из кучи.

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

Я открыл для себя Nim, когда искал правильный инструмент для написания игры, HoorRace, преемник моей текущей DDNet игры/мода Teeworlds.

(прим. пер. На синтаксис Nim имели влияние Modula 3, Delphi, Ada, C++, Python, Lisp, Oberon.)

Запускаем!

Да, эта часть всё ещё не захватывает, но просто следите за продолжением поста:

for i in 0..10:
  echo "Hello World"[0..i]

Эта небольшая статья поможет:

• Ознакомиться с событийной моделью построения проектов и решений MS Visual Studio;
• Понять, как получить поддержку Command-Line режима devenv.exe для VSPackage (где он изначально не предусмотрен);
• Понять, как эмулировать схожую модель событий от MSBuild Tools и транслировать на главный плагин;
• Узнать, как работать по приоритетной подписке;
• Узнать варианты получения контекста построения при обработке событий Visual Studio / MSBuild Tools;
• Узнать об оценке MSBuild Property & MSBuild Property Functions;
• Получить общие сведения межмодульного взаимодействия на слое абстракции для разнородных компонентов системы.

Синопсис

Мне довольно часто приходиться заниматься автоматизацией тех или иных процессов, поэтому не мудрено, что часть решений рано или поздно коснулись и Visual Studio.

На самом деле, эта статья, или даже заметка — результат рабочего и уже давно написанного плагина, который еще года 2 назад являлся лишь побочным продуктом при работе над одним проектом на C++. Однако мой дебют на Хабрахабре будет, пожалуй, с этого.

• Игровой backend: из каких модулей он должен состоять?
• Расчет параметров персонажа: виртуальные методы или сложение массивов?
• Логика поведения: на каком уровне она должна находится?
• Перемещение персонажей: кто этим должен управлять?

        Сегодня мы продолжим знакомиться с разработкой и проектированием он-лайн игры на примере космической ММО RPG «Звездные Призраки». В этой статье речь пойдет о backend'е на С++ и она будет насквозь техническая.

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

        В статье мы сосредоточимся именно на архитектурных решениях применительно к backend'у MMO RPG в реальном времени. Исходного кода будет не много и он точно не будет содержать таких специфических для С++ вещей как множественное наследование или шаблоны. Задача данной статьи помочь в проектировании игрового сервера и ознакомить всех желающих со спецификой игрового backend'а.

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

Когда результат SQL-запроса влечет бесконечные приведения типов ко всевозможным вариантам типов полей. Когда код заполнен малопонятной логикой с гигантским перебором перегрузок по типам boost::variant. Когда не знаешь, как принять аргумент произвольного типа по RPC-протоколу. Тогда требуется механизм эмуляции динамической типизации в C++. Расширяемый и удобный, создающий понятный API. Такой, что не требует предопределенного списка типов и не заставляет работать с указателями на базовый класс. Такой механизм есть — нам поможет двойная диспетчеризация!

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

Решил я как-то год назад заняться ГеймДевом. Поздновато, конечно, но история не об этом. Сразу решил, что надо писать для мобильных устройств. Направление перспективное и для меня оказалось очень интересным.

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

Достал книгу на русском, Внимательно прочитал половину, сделал детскую игру «Быки и Коровы». Здесь не о чем говорить, это был тестовый проект.

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

Теперь стал вопрос о том, чтобы сделать проект немного посерьёзней. Везде советуют начинающим браться сначала за что-то простое, так сказать попробовать, научиться на своих ошибках и т.д. Я уже начал подготавливаться, чтобы написать старую и всем знакомую Lines, но вот тут стала необходимость для одного проекта написать что-нибудь на Android. И так родилась идея написать платформер. И вот, собственно говоря, история как раз об этом.

Когда вы захотите обновить версию Visual C++ компилятора (например, перейти с Visual Studio с 2013 на 2015), будет не лишним узнать, почему вы можете столкнуться с тем, что код, который прежде успешно компилировался и выполнялся, теперь будет вызывать ошибки компиляции и/или ошибки времени выполнения.
Эти проблемы могут быть вызваны многочисленными изменениями компилятора для соответствия стандарту С++, изменениями в сигнатурах функций или изменениями расположения объектов в памяти.

igzip — высокопроизводительная библиотека для выполнения сжатия gzip или DEFLATE. Она была изначально описана в статье Высокопроизводительное сжатие DEFLATE для процессоров с архитектурой Intel. В этой статье описывается связанный выпуск исходного кода, содержащий необязательные (во время сборки) оптимизации для повышения степени сжатия геномных наборов данных в форматах BAM и SAM. igzip работает примерно в 4 раза быстрее, чем Zlib при настройке на максимальную скорость, и с примерно такой же степенью сжатия для геномных данных. Мы считаем, что igzip можно схожим образом оптимизировать для других областей применения, где наборы данных отличаются от обычных текстовых данных.

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

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

Итак, весь тернистый путь компиляции и оптимизации нашего приложения можно разбить на 7 шагов. Пошагали!