C++ *

Данная статья является продолжением первой части.
Продолжаем мучить Boost.Python. В этот раз настала очередь класса, который нельзя ни создать, ни скопировать.
Обернём почти обычную сишную структуру с необычным конструктором.
И поработаем с возвращением ссылки на поле объекта C++, так чтобы сборщик мусора Python его не удалил ненароком. Ну и наоборот, сделаем альтернативный вариант, чтобы Python прибрал мусор после удаления того, что ему отдали на хранение.
Поехали…

Boost.Python во всех отношениях замечательная библиотека, выполняющая своё предназначение на 5+, хотите ли вы сделать модуль на С++ для Python либо хотите построить скриптовую обвязку на Python для нативного приложения написанного на С++.
Самое сложное в Boost.Python — это обилие тонкостей, поскольку и C++ и Python — два языка изобилующие возможностями, и потому на стыке их приходится учитывать все нюансы: передать объект по ссылке или по значению, отдать в Python копию объекта или существующий класс, преобразовать во внутренний тип Python или в обёртку написанного на C++, как передать конструктор объекта, перегрузить операторы, навесить несуществующие в C++, но нужные в Python методы.
Не обещаю, что в своих примерах опишу все тонкости взаимодействия этих фундаментальных языков, но постараюсь сразу охватить как можно больше частоиспользуемых примеров, чтобы вы не лазили за каждой мелочью в документацию, а увидели все необходимые основы здесь, или хотя бы получили о них базовое представление.

Завершающая часть перевода интервью (первая часть, вторая часть), взятого у создателя Стандартной библиотеки шаблонов Алекса Степанова в 1995 году. Здесь Алекс рассказывает о том, почему в шаблонах не включена поддержка персистентности и серилазизации, о будущем библиотеки и о связи ООП и обобщённого программирования.

Алекс, STL не реализует объектную модель персистентности (постоянного хранения) объектов. Map и Multimap являются особенно хорошими кандидатами для постоянного хранения контейнеров как инвертированных индексов в базах данных постоянного хранения объектов. Скажите, работали ли Вы в этом направлении или же Вы можете хотя бы прокомментировать реализации этой идеи?

Это обстоятельство отмечалось многими. STL не реализует персистентность по уважительной причине. STL настолько велика, насколько можно было себе представить в то время. Я не думаю, что любой больший набор компонентов прошёл бы через Комитет по стандартам. Но персистентность является тем, о чём думали некоторые люди тогда. При проектировании STL и особенно во время проектирования компонента-распределителя, Бьярн отметил, что распределители, которые инкапсулируют памяти модели, могут быть использованы для инкапсуляции модели постоянной памяти. Прозрение принадлежит Бьярну, и это важное и интересное прозрение. Несколько компаний, разрабатывающие объектные базы данных, рассматривают эту идею. В октябре 1994 года я посетил встречу Группы по системам управления объектными базами данных. Я выступил с докладом по STL, и после был большой интерес к тому, чтобы сделать контейнеры с их развивающимся интерфейсом соответствующими STL. Они не рассматривали распределители как таковые. Некоторые из членов группы, однако, пытались выяснить, могут ли распределители быть использованы для реализации персистентности. Я ожидаю, что в течение следующего года появятся хранилища объектов с STL-совместимыми интерфейсами, которые будут вписываться в рамки STL.

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

Ниже представлен «проект 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 и о том, насколько он красив.
Да, красив. Позвольте мне объясниться.