Многим программистам знакомы концепции пар и кортежей (pair и tuple) — их реализации есть в STL, Boost (и может быть где-нибудь еще). Для тех, кто не знает, что это такое, я коротко поясню — это шаблоны, позволяющие сгруппировать несколько значений (пара — только 2, tuple — много) с целью хранить\передавать\принимать их вместе.
Пример из MSDN:

   pair <int, double> p1 ( 10, 1.1e-2 );
   pair <int, double> p2 = make_pair ( 10, 2.22e-1 );
   cout << "The pair p1 is: ( " << p1.first << ", " << p1.second << " )." << endl;
   cout << "The pair p2 is: ( " << p2.first << ", " << p2.second << " )." << endl;
 

Поначалу идея кажется заманчивой, ведь:

1. Вместо передачи в функцию нескольких векторов одинаковой размерости можно передать только один вектор пар\кортежей, не заботясь о проверке их соответствия.
2. Можно легко вернуть из функции набор значений, не мороча голову с указателями или ссылками в out-параметрах (для многих это сложно)
3. Можно избежать создания кучи мелких структур из 2-3 полей (меньше кода — лучше).

Но есть и тёмная сторона этой силы.

Некоторое время назад я увлекался созданием оконной библиотеки под Windows на C++. И сегодня я расскажу как написать простую обертку над WinAPI для создания оконных приложений.

Введение

Совсем недавно Microsoft выпустили beta-версию инструментария для работы с Kinect – Microsoft Research Kinect SDK. В инструментарии доступны заголовочные файлы, библиотека, а также примеры использования в приложениях на C++. Но наличие самого SDK не решает проблему с отсутствием доходчивых примеров и документации. Заметно, что Microsoft больше ориентируется на .NET разработчиков, поэтому, например, на официальном форуме подавляющее большинство топиков связаны с C#, а гуглопоиск при попытке найти какое-либо описание API для Kinect выдает всего несколько ссылок, и те — на официальную документацию.

В этой статье рассматриваются варианты использования Microsoft Kinect, а также упомянутого выше программного инструментария в C++ приложениях и в связке с библиотекой wxWidgets.

Привет Хабр! Хочу представить свою С/С++ библиотеку libral, которая с недавних пор стала open source под лицензией GPL3. Возможно кому-то она будет полезна. Библиотека предоставляет единый интерфейс к различным алгоритмам сжатия данных без потерь.
На данный момент поддерживаются библиотеки:

• libc — без сжатия
• zlib — www.zlib.net
• lzo — www.oberhumer.com/opensource/lzo
• snappy — code.google.com/p/snappy
• bzip2 — www.bzip.org

В C# есть делегаты. В python есть делегаты. В javascript есть делегаты. В Java есть выполняющую их роль замыкания. А в C++ делегатов нет O_O. Многие талантливые программисты успешно борются с этим недостатком, разрабатывая и используя sigslots, boost::function и другие ценные и нужные библиотеки. К сожалению, большинство реализаций отличаются не только методом использования, но также эпической сложностью применяемой шаблонной магии. Дабы при изучении исходников boost::function волосы не вставали дыбом, я написал эту небольшую статью, показывающую как самым простым и топорным способом реализовать делегат на C++. Описанная реализация является иллюстративной, имеет множество недостатков и ее вряд ли можно применить в серьезных проектах — зато она максимально простая и позволяет ознакомиться с предметной областью не разбирая трехэтажные шаблоны sigslots :).

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

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

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

Хочу поделиться с вами моим собственным решением для обфускации строк в программе, которое хоть и даёт лишь минимальную защиту, но является 1) бесплатным 2) лёгким 3) почти не портящим внешний вид кода 4) новым, которое кракер скорее всего в данной конкретной конфигурации ещё не видел.

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

Бэкапил историю сообщений из Skype самописной утилиткой, год назад она работала отлично, а теперь стала люто тормозить. Это неприемлемо, тк. в том числе ради скорости экспорта она и была написана, поэтому полез в профайлер. По итогам узнал всякое и получил множественные просветления. Оказывается, breakpoint на функцию в подгруженной системной DLL ставить приходится с подвывертом, а не просто по имени, но таки можно и нетяжело. Оказывается, Skype API написан местами зверски криво, отчего и тормозища. Оказывается, чужие бинарники иногда можно очень легко подхачить и подоптимизить (слава MS Research!). Оказывается, профайлер может сильно врать, а не просто слегка подбрехивать. Ключевые слова для нетерпеливых: C++, VS, CodeAnalyst, Skype COM API, MS Research, Detours, SQLite; а для всех остальных подробности под катом.

Введение

Так уж сложилось, что моя работа тесно связана с математическим моделированием физических процессов. Математическое моделирование — это совершенно особенная область программирования. Расчет даже относительно простого физического процесса может занимать несколько дней и даже недель. Поэтому на первый план выходит производительность программы, пускай даже в ущерб удобству написания и чтения кода. Однако до недавнего времени быстродействие моих программ меня мало заботило: вполне хватало грубых сеток, для которых расчеты занимали что-то около суток. Но постепенно сетки становились все подробнее, и время работы программ неуклонно росло. Тогда я стал искать узкие места в своей программе. Сначала в алгоритмах. Потом дело дошло до структур данных. И тут меня очень заинтересовал вопрос «а что же лучше использовать для хранения векторов: массивы или контейнеры?»

Технология C++ Accelerated Massive Parallelism (C++ AMP) построенная на платформе Microsoft DirectX, согласно новому блог-посту. Microsoft планирует сделать эту технологию частью следующего Visual C++ компилятора и полностью интегрировать в следующую версию Visual Studio, под кодовым именем Visual Studio vNext (скорее всего выйдет под названием Visual Studio 2012).

Наверное, все любители языка C++, которые использовали другие языки, такие как C#, удивляются: почему же в плюсах нет property? Ведь это действительно удобное средство, позволяющее полностью контролировать доступ к членам класса. Недавно и я заинтересовался данным вопросом. Подумав, полистав Страуструпа и наконец, погуглив, я пришёл к выводу, что property можно реализовать средствами языка. Думаю многие уже видели разнообразные реализации, например, от microsoft, но для кого-то, надеюсь, это будет интересным открытием.
В статье вы найдёте один из возможных вариантов реализации свойств при помощи шаблонов.

О чем речь?

Иногда в старом и добром C++ возникает потребность в реализации SOAP сервисов. Конечно, истинные любители программирования бросаются писать сервер самостоятельно, я же предпочитаю не тратить время впустую и использовать готовые библиотеки. Сегодня я хочу осветить (совсем чуть-чуть) тему использования библиотеки gSOAP в своих приложениях на C++ в качестве сервера.

Одна интересная реализация подсчёта числа установленных битов в файле. Код на языке C++ с обильным использованием STL. Если всё так хорошо, то почему это в блоге «Ненормальное программирование» (читатели настоятельно рекомендовали перенести в блог C++) спросите Вы? Сейчас увидите :)

Одно время приходилось постоянно работать с сетевыми данными и в особенности с заголовками сетевого и транспортного уровней модели OSI. Постоянно напрягал тот факт, что многие поля были в Big-Endian, а код выполнялся на архитектуре Little-Endian. Ну невозможно было постоянно вызывать ntohl(), htonl(), ntohs(), htons()...


Автор фото: Ciroduran, источник фото: flickr.

Не так давно на работе встала передо мной задача написать прогу в среде C++ Builder, и был в ней момент, когда нужно парсить командную строку. К задаче прилагалось так же волшебное «можешь юзать все исходники, которые есть. Лежат они тут: ...». Первым делом полез, конечно, по адресу… и нашел там жутко ветвящуюся структуру кода, в которой попытался разобраться и решил, что подгонять ее под себя – ад. Поэтому пришло мне в голову написать что-то подобное Qt-шной системе сигналов и слотов, только для C++ Builder’а и аргументов командной строки.
Итак, начнем. Идея такова: анализ командной строки сводится к проверке, есть ли в аргументе спецсимвол (в моем случае – это «-» – был взять стандарт Linux). В зависимости от этого аргумент читается как имя параметра или его значение. Для вызова функций обработки используется ассоциативный массив, т.е. массив в котором в качестве ключей будут имена доступных параметров, а значений – адреса функций обработки конкретного параметра. Вот, в общем-то, и все. Приступим к реализации?

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

Аннотация

Это третья статья, просвещенная порождающим шаблонам проектирования и связанным с ними вопросами. Здесь мы рассмотрим излюбленные приемы при создании объектов: фабрики, заводы, абстрактные фабрики, строители, прототипы, мультитоны, отложенные инициализации, а также немного коснемся pimpl идиомы или шаблона “мост”. Использование синглтонов было подробно рассмотрено в первой [1] и второй [2] статьях, однако, как вы увидите в дальнейшем, синглтоны часто используются совместно с другими шаблонами проектирования.

Когда вставал вопрос о тестировании кода, я не задумываясь использовал boost::test. Для расширения кругозора попробовал Google Test Framework. Помимо всяких имеющихся в нем плюшек, в отличии от boost::test проект бурно развивается. Хотел бы поделиться приобретенными знаниями. Всем кому интересно прошу

Есть мнение, что алгоритм std::fill() работает столько же эффективно на простых типах, как и старый добрый memset() (так как он его и использует в некоторых специализациях).

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

Доброго времени суток, Хабралюди!

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

Эта статья является продолжением моей первой статьи “Использование паттерна синглтон” [0]. Сначала я хотел все, что связано со временем жизни, изложить в этой статье, но объем материала оказался велик, поэтому решил разбить ее на несколько частей. Это — продолжение целого цикла статей про использование различных шаблонов и методик. Данная статья посвящена времени жизни и развитию использования синглтона. Перед прочтением второй статьи настоятельно рекомендуется ознакомиться с моей первой статьей [0].

В предыдущей статье была использована следующая реализация для синглтона:

template<typename T>
T& single()
{
    static T t;
    return t;
}

Функция single возвращала нам заветный синглтон. Однако данный подход имеет изъян: в этом случае мы не контролируем время жизни объекта и он может удалиться в тот момент, когда мы хотим этим объектом воспользоваться. Поэтому следует использовать другой механизм создания объекта, используя оператор new.