C++ *

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

Ниже представлен «проект NULL», тот самый костяк, с которого обычно все и начинается. У меня.

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

LLVM — это набор «кирпичиков» для построения компиляторов, а clang — новый компилятор C++ на его основе. По сравнению с gcc — обеспечивается большая скорость компиляции при сравнимом качестве кода, более человеко-понятные исходники т.к. они не несут десятилетия жесточайшей C-only разработки как в gcc.

Помимо этого, Clang и llvm распространяются под лицензией BSD, в отличии от GPLv3 у GCC. BSD позволяет не открывать исходники при распространении исполняемых файлов компилятора.

С LLVM+CLang будет интересно поиграть любому кто когда-либо хотел написать свой компилятор, или считает, что компилятор собранный своими руками дает более теплый бинарный код.

БОльшая часть часть разработчиков llvm/clang используют его под Linux/MacOS — и там его сборка/установка не вызывает каких либо проблем, путь основательно протоптан. А вот в случае windows ситуация несколько осложняется — об обходе нескольких граблей при сборке, о том, что связывает clang и gcc, и какие баги придется фиксить в релизе — под катом.

На хабре много статей посвященных редактору Sublime Text 2. Обычно они рождают за собой множество комментариев, где сторонники ST2 и всевозможных других редакторов (а также полноценных IDE) предаются веселому процессу «достоинствометрии».
Однако, среди комментариев мне лично ни разу не встречалось упоминаний о плагине SublimeClang, который кардинально меняет работу C++ программиста в этом редакторе. Поиск по хабру выдал всего 4 упоминания плагина в комментариях.
Не знаю, чем вызвано такое игнорирование. Хорошие вещи не обсуждаются? ST2 не используют C и С++ разработчики? Своей статьей я хочу исправить ситуацию. Я расскажу о некоторых, возможно не очевидных, особенностях установки и настройки, а также поделюсь парой собственных приемов и скриптов.

О плагине

Итак, плагин обеспечивает автодополнение кода и проверку ошибок прямо по ходу написания программы. Для файлов C/C++/ObjC/ObjC++ плагин заменяет стандартное автодополнение редактора на свое собственное. Для этого, плагин в фоне прогоняет исходник через компилятор clang, который формирует AST. Полученную информацию плагин использует для интеллектуальных подсказок автодополнения.
Ближайший аналог, который я могу подобрать — это функция IntelliSense в MS Visual Studio.
Использование информации из первых рук — от компилятора — позволяет плагину правильно узнавать, какие переменные, функции, типы и т.п. доступны в данной конкретной точки программы. Так же, в какой-то мере работают Go to definition (alt + d, alt + d) и Go to implementation (alt + d, alt + i). Список остальных горячих клавиш доступен на странице проекта.

Данная заметка спровоцирована интересным топиком на habrahabr.ru/post/166201 о Switch операторе для C++ и желанием предоставить сообществу еще одну идею и воплощение на оценку.

Одним из недостатков оператора Switch в C++ является ограниченность по типу данных к которым возможно его применение и автор статьи по ссылке привел интересное решение.

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

Т.е. Еще один «switch для строк» — но не только для строк и не только «switch».

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

Идея заключается в использовании тернарного оператора ?: в условии Switch

допустим “test” тестовая переменная а “var_ i” i=1,..,4 это переменные с которыми ее нужно сравнить

из конструкции

bool bool_1, bool_2, bool_3, bool_4;
bool_1 = (test == var_1);
bool_2 = (test == var_2);
bool_3 = (test == var_3);
bool_4 = (test == var_4);

видно, что bool_ i i=1,..,4 это логические условия а переменные test и var_i i=1,..,4 могут быть любых типов, главное они однотипные.

идея в следющей строке

switch((bool_1?1:0)|(bool_2?2:0)|(bool_3?4:0)|(bool_4?8:0))

и заключается в том что switch будет получать для принятия решения результат операции “или” на двоичных степенях двоек.

Это дает не только класический switch, но и обещанную обработку всех истинностных вариантов т.е. всех 16 вариантов для 4-х условий.

Условия в switch можно добавлять в любом количестве сохраняя последовательные степени двойки в втором аргументе каждого тернарного оператора

Объяснение далее:

Одной из основ разработки игр является обработка сообщений поступающих во время каких-либо событий (Events). Все видеоигры, от тенниса до очень сложных игр для ПК и консолей, используют т.н. события для взаимодействия с игроком. Эти события могут поступать от клавиатур, мышей, джойстиков, геймпадов, и т.д., а также от самой операционной системы. Важно понимать, как они работают, если мы хотим надлежащим образом обрабатывать взаимодействие пользователя с игрой. Мы уже использовали события, но только для закрытия нашего окна, теперь мы будем глубже разбираться с тем, как получать события от пользователя.

Все более или менее знающие Python разработчики знают про такую жуткую вещь как GIL. Глобальный блокировщик всего процесса до тех пор пока Python выполняется в одном из потоков. Он даёт потоко-защищённость методами сравнимыми с садизмом, поскольку любая неявная блокировка в многопоточном приложении смерти подобна, всё что опиралось на параллельное выполнение, умирает в мучениях, раз за разом натыкаясь на блокировку GIL.
Известно что по сей день из-за этого скорбного факта программисты на C++ используют Python-обёртки по большей части лишь в однопоточных приложениях, а программисты на Python пытаются всех убедить, что им и так неплохо живётся.
Казалось бы, если поток порождён в C++, он не знает ни о каком GIL, используй Python без блокировок и радуйся. Радость разработчика однако закончится уже на втором потоке запросившем область глобальных переменных без блокировки.
Однако есть путь ведущий к светлому будущему!
Этот путь был изначально в таком языке как Perl, он же поддерживается в Си-API языка Python и я ума не приложу почему подобный механизм не включен в один из стандартных модулей Python! Способ по сути сводит использование различных под-интерпретаторов Python в разных потоках, причём используя свой GIL для каждого(!!!) без всякого шаманства и магии, просто последовательно вызвав несколько функций и стандартного набора Си-API языка Python!

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

Алекс, где и когда вы решили предложить STL как часть определения ANSI/ISO Стандарта C++?

В течение лета 1993 г., Эндрю Кёниг посещал Стэнфорд для преподавания курса C++. Я показал ему кое-что из наших материалов, и, я думаю, он был искренне захвачен увиденным. Он организовал приглашение для меня в качестве докладчика на ноябрьской встрече Комитета по Стандарту C++ в Сан-Хосе. Я прочитал доклад, обозначенный как «Наука программирования на C++». Моя речь была скорее теоретическая. Основная позиция заключалась в том, что существуют фундаментальные законы, которые связывают очень примитивные операции, такие как конструкторы, присваивание и равенство. C++ как язык не навязывает никаких ограничений. Вы можете определить собственный оператор равенства для того, чтобы выполнить умножение. Но равенство должно быть равенством, и оно должно быть рефлексивной операцией. A должно быть равно A. Оно должно быть симметричным. Если A равно B, то B равно A. A должно быть транзитивным. Обычные математические аксиомы. Равенство присуще другим операциям. Имеются аксиомы, связывающие конструктор и равенство. Если вы конструируете объект с копирующим конструктором из другого объекта, то два объекта должны быть равны. C++ не обязывает к этому, но это один из основных законов, которому мы должны подчиниться. Присваивание должно создавать одинаковые объекты. Т.о., я представил группу аксиом, которые связаны с этими основными операциями. Я немного говорил об аксиомах итераторов и показал некоторые обобщенные алгоритмы, обрабатывающие итераторы. Это была двухчасовая лекция и, я думаю, весьма сухая. Однако она была очень хорошо принята. В то время я не думал об использовании этой штуки в качестве части стандарта, т.к. обычно воспринималось, что это была некая продвинутая техника программирования, которая не стала бы широко использоваться в «реальном мире». Я думал, что у практичных людей не было никакого интереса к любой из этих работ.

Думаю, что документ на который наткнулся будет также полезен и другим программистам.

Мне давно хотелось иметь все STL-контейнеры и их методы в более наглядном и удобном виде. До сего момента я не знал о том, что на известном ресурсе посвященном С++ cppreference.com выложен полезный PDF-файл содержащий в себе как раз то что мне надо. Вот прямая ссылка на container-library-overview-2012-12-27.

В этом документе учтены как C++03, так и C+11. Оба помечены разными цветами, что достаточно быстро дает понять с какой версии стандарта доступен тот или иной контейнер.

Взяв за основу первый урок, мы будем углубляться в мир поверхностей SDL. Как я уже говорил, SDL поверхности, в основном, это изображения, сохраненные в памяти. Представьте себе, что у нас есть пустое окно размером 320x240 пикселей. В системе координат SDL, окно представлено следующим образом:

Давно хотел написать полезную статью и вот наконец нашёл подходящий информационный повод.

Речь в этой статье пойдёт о создании примитивного web сервера работающего по https протоколу. Мы на пишем серверную часть, а в качестве клиентской части будет выступать любой из браузеров.
В итоге мы получим максимально упрощённый пример примитивного web сервера который можно будет улучшать и затачивать под свои задачи.

Я поискал по хабру перевод уроков с этого сайта, но нашлось только одно упоминание, да и то — в комментариях:



Потому и решил исправить положение, попытался дополнить и разнообразить примеры своими наработками, а заодно попрактиковался в переводе. Также, поскольку моей любимой ОС сначала была WinXP а теперь Ubuntu, постараюсь сделать кроссплатформенные примеры, захватив как можно больше нюансов настройки для этих платформ. В данной серии уроков рассматривается создание фрэймфорка, достаточного для начала разработки 2D игр.
Что из этого получилось

В последние годы, когда спрос на C++ снова растёт, интересно заглянуть в недалёкое прошлое и вспомнить, как создавалась эта классическая платформа разработки. В данном вопросе безусловно содержательными являются книги Страуструпа, вроде «Дизайна и эволюции C++». Однако, не менее интересно услышать о языке от самых первых его последователей, а иногда и полноценных соавторов. Пожалуй, наиболее известным из них является наш (в общем-то :) соотечественник Алекс Степанов, автор Стандартной библиотеки шаблонов. Интервью, приводимое далее, было взято у Алекса в 1995-м году колумнистом журнала Dr.Dobbs Элом Стивенсом. Материал будет интересен как начинающим изучать C++, так и опытным пользователям языка.

Алекс, расскажите нам что-нибудь о вашем cтоль длительном интересе к обобщённому программированию.

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

К сожалению, стандарт C++ не допускает применения операторов switch-case к строковым константам. Хотя в других языках, вроде C#, такая возможность имеется прямо «из коробки». Поэтому, понятное дело, многие C++ программисты пытались написать свою версию «switch для строк» — и я не исключение.
Для C++03 решения не отличались красотой и лишь усложняли код, дополнительно нагружая приложение в рантайме. Однако с появлением C++11 наконец-то появилась возможность реализовать такой код:

   std::string month;
   std::string days;

   std::cout << "Enter month name: ";
   std::cin  >> month;

   SWITCH (month)
   {
   CASE("february"):
       days = "28 or 29";
       break;

   CASE("april"):
   CASE("june"):
   CASE("september"):
   CASE("november"):
       days = "30";
       break;

   CASE("january"):
   CASE("march"):
   CASE("may"):
   CASE("july"):
   CASE("august"):
   CASE("october"):
   CASE("december"):
       days = "31";
       break;

   DEFAULT:
       days = "?";
       break;
   }

   std::cout << month << " has " << days << " days." << std::endl;

Реализация этой конструкции весьма проста. Она основана на constexpr-функциях из C++11, благодаря чему почти все вычисления производятся ещё на этапе компиляции. Если кого-то интересуют её детали, добро пожаловать под кат — благо на Хабре о «switch для строк» почему-то ничего не сказано.

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

Предыстория

В процессе разработки одного B2B проекта возникла необходимость обращения к нашему приложению из различных систем вроде 1C, Oracle, MS Sql Server. Первый «универсальный» вариант, который пришел в голову – использовать веб-сервисы. Но, к сожалению, у вышеупомянутых систем несколько разное понимание этого стандарта (например, не факт, что тот же oracle и 1C будут понимать друг друга), кроме того нам не хотелось раздувать проект использованием тяжелых сторонних библиотек (на тот момент мы уже использовали boost и Intel TBB, притягивать же еще Qt или gSoap нам не хотелось).
Поэтому было решено писать свой велосипед.

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

Понятно, что необходимость написать код, который пройдет тестирование, — дисциплинирует и помогает грамотнее планировать архитектуру. Тем не менее, первая мысль о покрытии юнит-тестами асинхронного кода на Boost.Asio была примерно такая: «Что?! Это абсолютно невозможно! Как можно написать тест, основанный на сетевой доступности узла?»

Сегодня вас ждет рассказ об исходном коде Doom 3 и о том, насколько он красив.
Да, красив. Позвольте мне объясниться.

2013 год только начинается. Чего же мы можем ожидать в нём для языка С++?

Ещё в прошлом году стало заметно значительное оживление в мире С++. Язык становится более динамичным, это заметно. С++03 правил много лет, без нового cтандарта С++ почти целое десятилетие мы наблюдали за развитием библиотек, статического программирования, вещей типа мета-программирования на шаблонах — и всё это неплохо эволюционировало. Но вот сам язык при этом никуда не двигался.

В 2013 году это изменится. Во-первых, начиная с этого года новый стандарт С++11 наконец станет доступен широкой аудитории, в виду полноценной его поддержке в Visual Studio 2012, Clang 3.2 и GCC 4.8. Влияние нового стандарта на библиотеки и фреймворки ощущается уже сейчас, к примеру многое из него нашло своё применение в Qt5. Но стандарту С++11 не суждено стать фундаментом разработки на следующее десятилетие. Скорее, его можно воспринимать как хороший промежуточный этап, шаг в сторону эволюции языка, которая продолжится в 2013-ом году и позже.

Это одна из причин почему я думаю, что 2013 год станет особенным для С++. В этом году начнется работа над новым стандартом — С++14. В апреле пройдет встреча комитета по стандартизации С++ в Бристоне (Великобритания) и мы уже сможем представить себе наброски будущего стандарта. В октябре пройдет встреча в Чикаго, где должен быть уже сформирован более или менее чёткий черновик, который в начале 2014-го станет новым ISO-стандартом.

Что же нам предложит С++14?

Понадобилось мне прикрутить Lua к проекту на C++. Писать обертки в ручную — лень (слишком много писать), готовые не подходили по тем или иным причинам. Решил написать свою. А потому задался вопросом, как максимально упростить интерфейс? От одной только мысли об этом в голову лезли жутчайшие конструкции из шаблонов. Так оно в последствии и оказалось, но гораздо проще, чем представлялось.

В C++11 появились шаблоны с переменным числом аргументов, это позволяет писать шаблонные функции/классы так, как в C++03 было невозможно вовсе. Такие шаблоны сильно упрощают задачу.

Первым делом понадобилось написать обертку над простейшими действиями с интерпретатором (можно было бы обойтись простыми вызовами к C API Lua, но держать в памяти кучу индексов различных значений в стеке мне не хочется. Поэтому я обернул их в несколько функций, которые помимо того, что избавляют от необходимости передавать в каждую функцию указатель на состояние интерпретатора, практически не требуют индексов, так как они имеют значения по умолчанию.

В итоге хотелось увидеть интерфейс близкий к следующему:

lua.export_function(some_function);

Предыстория

Пару лет назад, в процессе выполнения одного проекта, связанного с выделением и сопровождением движущихся объектов, было просмотрено немало алгоритмов вычитания фона, и в итоге одним из самых интересных оказался тот, о котором дальше и пойдет речь. Основной его недостаток — куча патентов, которыми он защищен. Но одно из несомненных достоинств — наличие библиотеки под Linux, которую разрешено использовать в некоммерческих проектах. На странице с его описанием можно найти эту самую библиотеку, а также demo-программы под Windows и Android, ссылки на патенты (где и можно найти основные описания алгоритма) и прочую интересную информацию.