Перед выполнением умножения C++ приводит множители к одному типу не короче int, а разрядность результата совпадает с разрядностью приведенных множителей. Для того, чтобы не потерять точность, иногда требуется для умножения выполнять дополнительные операции.

Многим программистам знакомы концепции пар и кортежей (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++, а также люди смыслящие в шаблонном метапрограммировании могут смело пропускать этот топик, ничего нового для себя они здесь не найдут. Однако, если после прочтения заголовка, у вас в голове еще не возникло решение данной задачи (и даже если оно возникло, но не при помощи шаблонов), то милости просим под кат.