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

Итак, о чём же идёт речь? Операционная система Windows, как известно, бывает 32-битной или 64-битной. На 32-битной Windows можно запустить только 32-битные приложения — а значит вопрос «это 32-битное приложение или 64-битное?» там попросту не имеет смысла, ответ известен заранее. Жизнь на 64-битном варианте Windows немного веселее — здесь можно запускать как 64-битные приложения (они считаются нативными), так и 32-битные, которые не являются родными для ОС, и выполняются они в специальной подсистеме WoW64 (Windows-on-Windows 64-bit). Подсистема эта включает в себя средства запуска 32-битного кода, отдельные ветки реестра и системные папки для работы 32-битных приложений в 64-битной среде.

Иногда бывает важно знать, является ли некоторый процесс, работающий в 64-битной Windows, действительно нативным 64-битным процессом, или WoW64-процессом (то есть 32-битным приложением, работающим в WoW64-подсистеме). Для этих целей Microsoft предлагает использовать функцию IsWow64Process(). Описание в MSDN достаточно детально, есть пара предупреждений на счёт способа её вызова, но в общём-то всё тривиально. Пример кода даже есть. Беда только в том, что в некоторых случаях эта функция врёт и определяет архитектуру процесса неверно.

Зачем нужен собственный торрент-трекер – вопрос не стоит. Причины могут быть разные. Поэтому сразу перейду к делу.

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

Примерно так думал я, рассматривая и оценивая каждого кандидата. Свой выбор я остановил на TorrentPier II. Оценивая плюсы и минусы следует отметить привычный для пользователей интерфейс, схожий с небезыствестным Rutracker-ом, и техническую поддержку, пусть и в виде форума. Трекер, после небольшой настройки, без проблем работает у меня уже более года.



Установка выглядит следующим образом (небольшая цитата из инструкции):

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

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

КДПВ

От переводчика:
Большинство моих знакомых для измерения времени в разного вида бенчмарках в С++ используют chrono или, в особо запущенных случаях, ctime. Но для бенчмаркинга гораздо полезнее замерять процессорное время. Недавно я наткнулся на статью о кроссплатформенном замере процессорного времени и решил поделиться ею тут, возможно несколько увеличив качество местных бенчмарков.

P.S. Когда в статье написано "сегодня" или "сейчас", имеется ввиду "на момент выхода статьи", то есть, если я не ошибаюсь, март 2012. Ни я, ни автор не гарантируем, что это до сих пор так.
P.P.S. На момент публикации оригинал недоступен, но хранится в кэше Яндекса

Функции API, позволяющие получить процессорное время, использованное процессом, отличаются в разных операционных системах: Windows, Linux, OSX, BSD, Solaris, а также прочих UNIX-подобных ОС. Эта статья предоставляет кросс-платформенную функцию, получающую процессорное время процесса и объясняет, какие функции поддерживает каждая ОС.

Привет, Хаброжители! У нас вышло 6-ое издание книги Гэйл Лакман Макдауэлл:

Книга «Карьера программиста» основана на опыте практического участия автора во множестве собеседований, проводимых лучшими компаниями. Это квинтэссенция сотен интервью со множеством кандидатов, результат ответов на тысячи вопросов, задаваемых кандидатами и интервьюерами в ведущих мировых корпорациях. Из тысяч возможных задач и вопросов в книгу были отобраны 189 наиболее интересных и значимых. Шестое издание этого мирового бестселлера поможет вам наилучшим образом подготовиться к собеседованию при приеме на работу программистом или руководителем в крупную IT-организацию или перспективный стартап. Основную часть книги составляют ответы на технические вопросы и задания, которые обычно получают соискатели на собеседовании в таких компаниях, как Google, Microsoft, Apple, Amazon и других. Рассмотрены типичные ошибки, которые допускают кандидаты, а также эффективные методики подготовки к собеседованию. Используя материал этой книги, вы с легкостью подготовитесь к устройству на работу в Google, Microsoft или любую другую ведущую IT-компанию.

1. Части I, II (синглплеер с авторитарным сервером)
2. Часть III (Появление врага)
3. Часть IV (Хэдшот!)

Предлагаю вашему вниманию перевод статьи Fast-Paced Multiplayer (Part I): Introduction.

Разработка игры — само по себе непростое занятие. Но мультиплеерные игры создают совершенно новые проблемы, требующие разрешения. Забавно, что у наших проблем всего две причины: человеческая натура и законы физики. Законы физики привнесут проблемы из области теории относительности, а человеческая натура не даст нам доверять сообщениям с клиента.

Современный C++: что это и как он появился?

В течение последнего десятилетия с приходом стандарта C++11, а перед этим — предваряющих его спецификации TR1 и библиотеки Boost, — в сообществе C++-разработчиков наблюдался массовый переход на новый стиль программирования, так называемый современный C++. Этот переход подразумевал введение в оборот таких приемов как ключевое слово auto, замыкания (лямбда-выражения), вариативные шаблоны и многое другое. C++ оказался благодатной почвой для экспериментов, и на свет появилось несколько библиотек, написанных в новом стиле. Те, кто смог разобраться в новых идиомах вроде SFINAE, диспетчеризации тегов, CRTP, генератора типов, безопасного bool и т.д., или хотя бы научился их воспроизводить, были награждены званием гуру.

Здравствуйте, уважаемые читатели.

Меня зовут Стас, я инженер команды DevOps Tooling в компании Align Technology.
В этой статье я попробую коротко рассказать про то, как в нашей компании внедрили статический анализ кода на основе PVS-Studio.

Введение

Приблизительно год назад мы задумались о том, чтобы внедрить в нашей компании статический анализ.
Мы и раньше использовали для этого различные средства, в том числе и для C/C++ проектов. Потому было интересно попробовать новый инструмент для известной задачи.
Инструмент, более совершенный, чем встроенный средства VS, cpp-check, интегрированный в Sonar.

В прошлый раз мы рассказали об Intel Management Engine (ME) — подсистеме, которая встроена во все современные компьютерные платформы (десктопы, лэптопы, серверы, планшеты) с чипсетами компании Intel. Эта технология многими воспринимается как аппаратная «закладка», и на то есть причины. Достаточно сказать, что Intel ME является единственной средой исполнения, которая:

• работает даже тогда, когда компьютер выключен (но электропитание подаётся);
• имеет доступ ко всему содержимому оперативной памяти компьютера;
• имеет внеполосный доступ к сетевому интерфейсу.

Ошарашенный присутствием такого компонента в компьютере, пользователь (получается, что именно «пользователь», а не «владелец») наверняка задавался вопросом: можно ли выключить Intel ME?

Эта статья целиком посвящена этому вопросу.

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

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

Эта статья является второй в цикле о библиотеке cpprt, предназначенной для добавления и использования минимальной метаинформации о классах С++.

В отличие от первой статьи, здесь почти ничего не будет о самой библиотеке cpprt. Я постарался подробно и максимально абстрагируясь от своей библиотеки изложить историю оформления библиотеки для её цивилизованной публикации на GitHub.

В статье затрагиваются вопросы лицензирования, структуры проекта и достаточно много внимания уделяется CMake.

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

В этом цикле статей будет я подробно рассказываю о том, как создавал свою микро-библиотеку, реализующую подобное поведение и как готовил её к публикации.

В последнее время много разговоров идет о том, что для C++ нужен свой пакетный менеджер подобный pip, npm, maven, cargo и т.д. Все конкуренты имеют простой и стандартизированный механизм подключения нестандартной библиотеки. В C++ же все действуют как умеют: кто-то прописывает в README список пакетов для Ubuntu, CentOS и других дистрибутивов, кто-то использует git submodule и скрипты для их сборки, кто-то использует CMake ExternalProject, кто-то копирует все исходники в один гигантский репозиторий, кто-то делает образ Docker или Vagrant.

Чтобы решить проблему был даже создан стартап — biicode, но он обанкротился и его будущее неизвестно. Взамен появился conan, дополняя зоопарк конкурентов — nuget, cget, hunter, cpm, qpm, cppget, pacm и даже gradle for c++.

Меня не устраивал ни один из перечисленных способов. Я было начал писать пакеты для Conan, но столкнулся с большим числом хаков, неразвитым API, отсутвием гайдлайнов и, как следствие, низкой вероятностью переиспользования чужих пакетов. И тут вспомнилось, что когда-то мне очень понравились идеи пакетного менеджера в NixOS. И подумал — а зачем плодить пакетный менеджер специально для C++, если те же задачи решает обычный пакетный менеджер? Нужно только чтобы он был достаточно гибким и простым в части описания пакета. И Nix идеально подошел на эту роль.

Как известно, в современных архитектурах x86(_64) и ARM виртуальная память процесса линейна и непрерывна, ибо, к счастью, прошли времена char near* и int huge*. Виртуальная память поделена на страницы, типичный размер которых 4 KiB, и по умолчанию они не отображены на физическую память (mapping), так что работать с ними не получится. Чтобы посмотреть текущие отображённые интервалы адресов у процесса, в Linux смотрим /proc/<pid>/maps, в OS X vmmap <pid>. У каждого интервала адресов есть три вида защиты: от исполнения, от записи и от чтения. Как видно, самый первый интервал, начинающийся с load address (соответствующий сегменту .text у ELF в Linux, __TEXT у Mach-O в OS X), доступен на чтение и исполнение — очень логично. Ещё можно увидеть, что стек по сути ничем не отличается от других интервалов, и можно быстро вычислить его размер, вычтя из конечного адреса начальный. Отображение страниц выполняется с помощью mmap/munmap, а защита меняется с помощью mprotect. Ещё существуют brk/sbrk, deprecated древние пережитки прошлого, которые изменяют размер одного-единственного интервала «данных» и в современных системах эмулируются mmap’ом.

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

• оптимально управляет уже выделенной памятью;
• значительно уменьшает количество обращений к ядру (ведь mmap / sbrk — это syscall);
• вообще абстрагирует программиста от виртуальной памяти, так что многие пользуются malloc’ом, вообще не подозревая о существовании страниц, таблиц трансляции и т. п.

Довольно теории! Будем щупать malloc на практике. Проведём три эксперимента. Работа будет возможна на POSIX-совместимых операционках, в частности была проверена работа на Linux и на OS X.

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

Как правило, язык C++ используют там, где требуется высокая скорость работы. Но на C++ без особых усилий можно получить код, работающий медленнее какого-нибудь Python/Ruby. Именно подобным кодом оперируют многочисленные сравнения Any-Lang vs C++.

Вообще, оптимизация бывает трех типов:

1. Оптимизация уже готового, проверенного и работающего кода.
2. Изначально написание оптимального кода.
3. Просто использование оптимальных конструкций.

Специально заниматься оптимизацией готового кода следует только после того, как проект закончен и используется. Как правило, оптимизация потребуется только в небольшой части проекта. Поэтому сначала нужно найти места в коде, которые съедают большую часть процессорного времени. Ведь какой смысл ускорять код, пусть даже на 500%, если он отнимает только 1% машинного времени? И следует помнить, что, как правило, гораздо больший выигрыш в скорости дает оптимизация самих алгоритмов, а не кода. Именно про данный ее вид говорят: «преждевременная оптимизация — зло» (с).

Второй тип оптимизации — это изначальное проектирование кода с учетом требований к производительности. Такое проектирование не является ранней оптимизацией.

Третий тип даже не совсем оптимизация. Скорее это избегание неоптимальных языковых конструкций. Язык C++ довольно сложный, при его использовании частенько нужно знать, как реализован используемый код. Он достаточно низкоуровневый, чтобы программисту пришлось учитывать особенности работы процессоров и операционных систем.

От переводчика

В мире победили языки высокого уровня и в мирах руби-питон-js разработчиков остается только разглагольствовать, что в плюсах не стоит использовать то или иное. Например, исключения, потому что они медленные и генерируют много лишнего кода. Стоило спросить "и какой же код он генерирует", как в ответ получил мямленье и мычание. А и правда — как же они работают? Ну что ж, компилируем в g++ с флагом -S, смотрим что получилось. Поверхностно разобраться не сложно, однако то, что остались недопонимания — не давали мне спать. К счастью, готовая статья нашлась.

На хабре есть несколько статей, подробных и не очень (при этом все равно хороших), посвященных тому, как работают exceptions в C++. Однако нет ни одной по-настоящему глубокой, поэтому я решил восполнить этот пробел, благо есть подходящий материал. Кому интересно как работают исключения в C++ на примере gcc — запаситесь pocket-ом или evernote, свободным временем и добро пожаловать под кат.

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

1 Введение

Настоящий документ содержит рекомендации по написанию программ на языке C++.

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

Но для появления ещё одного списка рекомендаций, помимо указанных источников, есть несколько причин. Основная причина — их излишняя обобщённость, поскольку зачастую требуется задать частные правила (в особенности правила именования). Данный документ содержит комментарии, что делает его более удобным в использовании при проведении ревизий кода, чем другие уже существующие документы. К тому же, рекомендации по программированию обычно вперемешку содержат описания проблем стиля и технических проблем, что не совсем удобно. Этот документ не содержит каких-либо технических рекомендаций по C++, делая упор на вопросах стиля.

При решении задач комбинаторики часто возникает необходимость в расчете биномиальные коэффициентов. Бином Ньютона, т.е. разложение также использует биномиальные коэффициенты. Для их расчета можно использовать формулу, выражающую биномиальный коэффициент через факториалы: или использовать рекуррентную формулу: Из бинома Ньютона и рекуррентной формулы ясно, что биномиальные коэффициенты — целые числа. На данном примере хотелось показать, что даже при решении несложной задачи можно наступить на грабли.

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

Исходные данные: дом, 3 фазы (15 кВт на дом), заземление штырем в 3 м длиной, автономная электросистема на базе солнечных батарей

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