C++ *

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

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

К своему большому удивлению, я не нашел простейших и прозрачных примеров а-ля «Hello world». Да, есть coursera и потрясающий Andrew Ng, есть статьи про нейронные сети на хабре (советую остановиться тут и прочитать, если не знаете самых основ), но нет простейшего примера с кодом. Я решил создать перцептрон для распознования «AND» или «OR» на своем любимом языке C++. Если вам интересно, добро пожаловать под кат.

Всем привет! Мы спешим поделиться радостными новостями: доступно для скачивания обновление для ReSharper Ultimate, состоящее из ReSharper 9.2, ReSharper C++ 1.1, dotCover 3.2, dotTrace 6.2, dotMemory 4.4 и dotPeek 1.5.

Hовые возможности ReSharper 9.2 включают в себя:

В этой статье речь пойдет о проверке системы документирования doxygen. Этот известный и широко используемый проект, по имеющему основания заявлению разработчиков, ставший фактически стандартом для документирования программного обеспечения, написанного на языке C++, еще не был проверен PVS-Studio. Doxygen просматривает исходный код программ и генерирует по нему документацию. Пришло время нам заглянуть в его исходники и посмотреть, что сможет найти PVS-Studio.

Представители 15 регионов России и 4 стран СНГ стали участниками мероприятия. Программа и ссылка на онлайн-трансляцию под катом

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

В конце предыдущего поста я просуммировал недостатки существующих интервалов:

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

Первая проблема особенно трудная, поэтому начнём с неё.

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

Компиляторы Intel обычно отдают предпочтение производительности и слабо заботятся о размере получаемого на выходе приложения. По умолчанию, фокус на максимальную скорость. Задача разработчика заключается в умении найти правильный баланс между скоростью выполнения приложения и используемыми оптимизациями компилятора, и его размером. В компиляторе Intel C/C++ имеется целый ряд возможностей, позволяющий контролировать этот баланс и делать размер приложения более приоритетным, чем его производительность. Давайте рассмотрим эти возможности.

Не очень хорошо помню, как я оказался в дебаггере DOSBox, и почему я ковырялся в 16-битном ассемблере, восстанавливая функцию распаковки ресурсных файлов MM3.CC – но это было здорово. Игра у меня появилась на какой-то из последних распродаж humble bundle, а потом в сети я наткнулся на страницу Джеффа Людвига, где описывались проблемы с модификацией игры, связанные с компрессией в MM3.CC. В частности, там было написано следующее:

Оказалось, что этот алгоритм довольно сложно взломать, и пока ещё никто не научился распаковывать эти данные.

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

DOS Packer

Посмотрев на MM3.EXE, я обнаружил, что это сжатый исполняемый файл DOS, с неким несжатым оверлеем, в начале которого стоит FBOV. Я ничего не знал про ДОСовские компрессоры, но я подсмотрел у Джеффа Людвига, что он использует вещь под названием “Universal Program Cracker” v1.11. Я нашёл версию 1.10 (выпущенную 25 июня 1997 года) и распаковал ехе. И мне удалось даже правильно обработать данные оверлея. И всё равно мне хотелось узнать название паковщика. Мне подсказали, что нужно использовать программу Detect It Easy, и действительно – она выдала:

EXECUTRIX-COMPRESSOR(-)[by Knowledge Dynamics Corp]
Borland TLINK(2.0)[-]

Для любителей истории могу рекомендовать старые ветки обсуждений, касающихся этого софта – от 1991 и 1995 годов:

https://groups.google.com/forum/#!topic/comp.os.msdos.programmer/QsjHLY6Kb4s
https://groups.google.com/forum/#!topic/comp.compression/IAj2-VHbtl4

В наше время никого уже не удивишь печатью картиночек на листе бумаги. Существует огромный выбор принтеров (в том числе и карманных). Многие из моих знакомых покупают или собирают 3D-принтеры. Я же хочу рассказать, как я снова изобретал велосипед. Итак, снова шаг назад — это история про 2D печать. Рассказ про то, как я делал мобильный принтер для телефона на основе термального принтера (принтер, который печатает на термобумаге — не нужны чернила, только специальная бумага и электричество), модуля bluetooth и ещё нескольких мелочей.
Хочу сразу предупредить, что в электронике и электротехнике я ничего не понимаю, что я принципиально не использовал готовых решений и библиотек. Поэтому это рассказ про рукожопство и велосипеды, про проблемы с которыми я столкнулся. Продолжайте чтение на свой страх и риск.

Волею судеб мне довелось заняться одной задачей автоматизации при помощи Python-скрипта. Изучая базовые конструкции, наибольший интерес у меня вызвал следующий код:

for index in range(0,10) :
  do_stuff()

Удобно, читаемо, лаконично (модно, стильно, молодежно)! Почему бы не организовать такой же цикл в С++? Что из этого вышло — под катом.

Посчастливилось мне как-то работать под руководством СТО, который по совместительству соавтор одного интересного проекта — GNU Gettext for Delphi and C++ Builder. Заценил я его только в Delphi, но этого достаточно чтоб понять принцип работы и разобрать какими фичами он обладает.
Вкратце это библиотека, позволяющая внедрять качественную локализацию в продукт общепринятым способом, работает так:

1. пишем код, почти как обычно;
2. запускаем приложение, сканирующее исходники на предмет текста, который нужно перевести;
3. генерим РО файлы;
4. переводим их в любом удобном редакторе;
5. компилим РО файлы в МО файлы;
6. на выбор либо внедряем перевод прямо в ЕХЕ либо кладём МО файлы рядом;
7. наслаждаемся результатом — язык приложения можно менять даже без перезапуска.

Чем этот способ крут:

• минимум изменений в коде приложения;
• никаких DLL и сторонних компонентов, всё OpenSource;
• РО файлы — достаточно распространенный инструмент перевода, что значит перевод можно даже отдать на аутсорс, и переводчик знает что с этим делать;
• перевод всего — формы, фреймы, месседжбоксы, и всё что угодно;
• корректный перевод слов в множественном числе в любом языке;
• полная поддержка Unicode.

Если вы задумались о том, чтобы освоить первый в своей жизни язык программирования, то вам придётся поломать голову над тем, а что же выбрать из многообразия существующих языков. В мире веб-разработки царит JavaScript, во многих ВУЗах и школах предлагают изучать Python. Если поспрашивать на форумах, то вам вывалят кучу вариантов, включая Haskell, Scala и Erlang. Богатство выбора хорошо почти в любом деле, и обилие языков программирования свидетельствует о том, что это направление научно-прикладной деятельности продолжает развиваться. Одному человеку уже не под силу изучить все существующие языки, поэтому приходится решать какой же язык лучше всего начать осваивать. Зачастую изучают то, что принято в конкретной компании или сегменте рынка. Но если вы только собираетесь сделать первые шаги на ниве программирования, то можно порекомендовать начать с одного из языков семейства С. Это будет наиболее дальновидным выбором, который поможет вам в карьере. Возможно, вы не станете ежедневно писать на этом языке, или не будете изучать его очень глубоко. Но если вы хотите, чтобы к вам относились как к серьёзному разработчику, то вам обязательно нужно владеть одним из языков семейства С.

Приветствую Хабр!
Пока наша команда разработчиков активно трудится над новым релизом FlyElephant, я решил устроить вебинар. На нем я расскажу об истории создания проекта, о функционале, который уже доступен и который появится в ближайшее время. Познакомлю с нашей программой бета-тестирования, а также продемонстрирую работу сервиса. В конце вебинара с радостью отвечу на все вопросы.
Приглашаю на него всех, кто связан с научными и высокопроизводительными вычислениями. Вебинар состоится 13 августа в 16.00. Регистрация на него здесь.

Введение

В последние несколько лет голосовые интерфейсы окружают нас все плотнее. То, что когда-то демонстрировалось только в фильмах о далеком будущем, оказалось вполне реальным. Дело дошло уже до встраивания движков для синтеза (Text To Speech — TTS) и распознавания (Automatic Speech Recognition — ASR) речи в мобильные телефоны. Более того, появились вполне доступные API для встраивания ASR и TTS в приложения.

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

Но для затравки — анекдот:
Урок русского языка в грузинской школе.
Учитель говорит: «Дети, запомните: слова сол, фасол и вермишел пишутся с мягким знаком, а слова вилька, булька, тарелька – без мягкого знака. Дети, запомните, потому что понять это невозможно!»

Раньше этот анекдот казался мне смешным. Теперь — скорее жизненным. Почему так? Сейчас постараюсь объяснить…

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

Бесконечные интервалы

Необходимость бесконечных интервалов обосновать чуть сложнее. Программисты на С++ редко сталкиваются с бесконечностями. В других языках это случается сплошь и рядом. В Haskell можно создать бесконечный список целых чисел, просто набрав [1..]. Это просто «ленивый список», элементы в котором создаются по требованию. Все бесконечные интервалы ленивые.

Для чего это может понадобиться? Допустим, в алгоритме, строящем новый список из N первых элементов другого. Или вы захотите «склеить» бесконечный список с конечным. Тогда вы получите конечный список пар элементов. Это совершенно нормальная практика.

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

Как мы уже писали конференцию C++ Siberia в Новосибирске будет открывать Эрик Ниблер. Чтобы поближе познакомить Хабр с этим замечательным человеком, мы решили перевести цикл его статей об интервалах. Сейчас Эрик работает над реализацией библиотеки Ranges по гранту, полученному от комитета стандартизации.

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

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

Затрагиваемые вопросы:

• Влияние программной архитектуры на потребление памяти и производительность;
• Различия при работе в 32 и 64 битных режимах;
• Различия между указателями и индексами массива;
• Влияние выравнивания данных внутри классов/структур;
• Влияние кеша процессора на производительность;
• Оценка стоимости поддержки ООП в языках высокого уровня;
• Признание факта необходимости учитывать низкоуровневые особенности платформы даже при разработке на языках высокого уровня.

Привет хабраплюсплюсовцам!

Хочу разобрать проблему компилятора avr-g++, из-за которой в разных дискуссиях про AVR и Arduino звучит «С++ — это не для микроконтроллеров, C++ жрёт память, C++ генерирует раздутый код — пишите на голом C, а лучше на ASM».

Для начала давайте разберёмся, в чём же преимущество C++ перед C. Концепций, которые добавляет C++ много, но самая значимая и самая эксплуатируемая — это поддержка ООП. Что такое ООП?

• Инкапсуляция
• Наследование
• Полиморфизм

Использование первых двух пунктов в C++ «бесплатно». Никакого преимущества программа на чистом C перед программой на C++ с инкапсуляцией и наследованием не имеет. Картина меняется, когда мы подключаем к действу полиморфизм. Полиморфизм бывает разным: compile-time, link-time, run-time. Я говорю о классическом run-time, т.е. о виртуальных функциях. Как только в своих классах вы начинаете добавлять виртуальные методы, чудесным образом растёт потребление как Flash-памяти, так и SRAM.

Почему так происходит и, что с этим можно было бы сделать, расскажу под катом.

Недавно наша команда завершила миграцию на 64-битную платформу довольного большого проекта (9 млн строк кода, 300Mb исходников). Проект занял полтора года. Хотя в силу NDA мы не можем привести название проекта, надеемся, что наш опыт окажется полезен другим разработчикам.