Должно ли C++ сообщество придерживаться стандарта или отойти от него, чтобы создавать лучшие вещи с Boost?


Погодите, не та библиотека.

В марте 2011 года комитет ISO C++ утвердил финальную версию черновика новейшего стандарта C++. Языка, который официально был стандартизирован в августе того же года и стал известен как C++ 11. Теперь, по прошествии 2 лет, мы можем оглянуться назад и посмотреть на некоторые проблемы, затронувшие язык(аж с момента принятия первого международного стандарта в 1998 году) и сравнить его финальный вариант с популярной C++ библиотекой Boost.

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

В интернете существует огромное количество описаний и туториалов о для того как написать собственную мини-ОС, даже существуют сотни готовых маленьких хобби-ОС. Один из наиболее достойных ресурсов по этой тематике, который хотелось бы особо выделить, это портал osdev.org. Для дополнения предыдущей статьи про PCI (и возможности писать последующие статьи о различных функциях, которые присутствуют в любой современной ОС), мы опишем пошаговые инструкции по созданию загрузочного диска с привычной программой на языке С. Мы старались писать максимально подробно, чтобы во всем можно было разобраться самостоятельно.

Итак, цель: затратив как можно меньше усилий, создать собственную загрузочную флешку, которая всего-навсего печатает на экране компьютера классический “Hello World”.

        Приветствую. Микроядра редко появляются на Хабре, но на неделе был  топик о GNU/Hurd, где вспоминали  разные микроядра и известные проекты. Было сказано много неточностей, так что я решил рассказать о том, как обстоят дела в отрасли с нашей точки зрения. Дело в том, что мы активно участвуем в развитии проектов Fiasco.OC и Genode и ведем разработки на их основе, так что нам есть о чем рассказать.

Любой опытный программист знает, что стандарт представления значений с плавающей точкой (IEEE 754) оставляет несколько зарезервированных значений, соответствующих не-числам (NaN, not-a-number). Стандартная библиотека Visual C печатает не-числа следующим образом:
Положительная и отрицательная бесконечности могут получаться при переполнении в результате арифметического действия — например, при делении на ноль, или при взятии логарифма от положительного нуля. (По стандарту IEEE, любое значение с плавающей точкой имеет определённый знак — не только не-числа существуют в положительном и отрицательном вариантах, но и нулей тоже два.)

Все мы привыкли к уже давно ставшему стандартному видению файловых систем: есть точка монтирования, и дерево node-ов ростёт от неё. Это удобно, привычно всем и проверенно десятилетиями. Но что если этих точек станет несколько?

Я хотел бы предложить Вам мой концепт того, как я это вижу. Пока, к сожалению, в теории, так как я не обладаю достаточным знанием проектирования файловых систем, но я более чем уверен, что на Хабре таких людей предостаточно, и моя цель — призвать их к конструктивной критике и обсуждению предложенной мною идеи.

Не так давно появилась задача создать простой сервис по созданию PDF отчетов на основе офисных документов для интранета. И вроде бы все просто, но вот с сохранением Excel в PDF возникли проблемы. Интересно? Прошу под кат.

Нет, я не раскрою вам загадку, скрывающуюся в названии MCp0411100101, но постараюсь развёрнуто ответить на комментарий nerudo, записанный в топике Процессоры «Мультиклет» стали доступнее:

Читая описание архитектурных новшевств этого мультиклета, мне хочется воспользоваться фразой из соседнего топика: «Я не понимаю».

Если кратко, то MCp — это потоковый (от dataflow) процессор с оригинальной EPIC-архитектурой. EPIC — это Explicitly Parallel Instruction Computing, вычисления с явным параллелизмом инструкций. Я применяю этот термин здесь именно в этом смысле, как аббревиатуру, а не как ссылку на архитектуру Itanium-ов. Явный параллелизм в MCp совсем другого рода.

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

В качестве минимальной базы для работы с PCI-устройствами будем использовать ядро, поддерживающее спецификацию Multiboot. Так удастся избежать необходимости писать собственный загрузочный сектор и загрузчик (loader). Кроме того, этот вопрос и так отлично освещен в интернете. В качестве загрузчика будет выступать GRUB. Грузиться мы будем с флэшки, так как с нее удобно загружать и виртуальную, и реальную машину. В качестве виртуальной машины будем использовать QEMU. В качестве реальной машины должна выступать машина с обычным BIOS-ом (не UEFI), поддерживающим загрузку с USB-HDD (обычно присутствует опция Legacy USB support). Для работы понадобятся Ubuntu Linux со следующими программами: expect, qemu, grub (их можно легко установить при помощи команды sudo apt-get install). Используемый gcc должен компилировать 32х битный код.

Этим летом appplemac опубликовал статью, посвященную изучению ассемблера MIPS. В ней, в частности, была рассмотрена команда syscall, генерирующая системный вызов. Автор сосредоточился на объяснении ассемблера MIPS, и на мой взгляд, недостаточно подробно рассказал, что же это такое — системный вызов. Я в тот момент занимался переносом проекта под архитектуру MIPS, разбирался с прерываниями, исключениями и системными вызовами.

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

Добрый день наблюдатели НЛО

Хотел описать, как собирал информацию о пользователях из AD и затем размещал информацию на SharePoint для удобочитаемости и в любой момент посмотреть о том, или ином пользователе нужную для нас информацию.
Опишу просто, так как всё оно было…

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

Предыстория:
Сам я работаю в техотделе одной брокерской компании в Торонто, Канаде. Так же у нас есть еще один офис в Калгари. Как-то после планового установления Windows обновлений на единственном доменном контроллере в удаленном офисе не запустился W32Time сервис, который отвечает за синхронизацию времени с внешним источником. Таким образом в течение около недели время на сервере сбилось приблизительно на 20 секунд. Наши рабочие станции на тот момент времени по умолчанию получали время с контроллера. Сами понимаете, что случилось. В торгах время очень важно, разница в секунды может решить многое. Первыми расхождение во времени, к сожалению, заметили наши брокеры. Наш отдел техподдержки, состоящий по сути из 3 человек за это распекли. Надо было срочно что-то делать. Решением было применение групповой политики, которая отсылала все машины к внутреннему NTP серверу, работающему на CentOS. Еще были проблемы с DC Barracuda Agent, сервисом, отвечающим за соединение контроллеров домена с нашим Веб фильтром, и еще парочка сервисов причиняла нам порой беспокойство. Тем не менее решили что-то придумать, чтобы следить за пару сервисами. Я немного погуглил и понял, что есть много решений, в основном коммерчиских для данной проблемы, но так как я хотел научиться какому-нибудь скриптовому языку, то вызвался написать скрипт на Питоне с помощью нашего местного линукс-гуру. В последствие это переросло в скрипт, который проверяет все сервисы, сравнивая их наличие и состояние со списком желаемых сервисов, которые к сожалению надо делать вручную отдельно для каждой машины.

Решение:

Эта статья — частичный перевод исчерпывающего руководства Дэвида Хоуэлса (David Howells) и Пола Маккени (Paul E. McKenney) распространяемого в составе документации Linux (Documentation/memory-barriers.txt онлайн версия).

Must read для разработчиков ядра/драйверов и очень познавательно для прикладных программистов.

Вступление

Все мы, время от времени, используем дебаггер для отладки программ. Отладчик может использоваться с C++, C#, Java и ещё сотней других языков. Он может быть как внешним (WinDbg), так и встроенным в среду разработки (Visual Studio). Но вы хоть раз задавались вопросом, как же работает отладчик?
И вам повезло. В этом цикле статей мы разберёмся от и до, как же работает отладка изнутри. В этой статье рассматривается только написание отладчика под Windows. Без компиляторов, линковщиков и других сложных систем. Таким образом, мы сможем отлаживать только исполняемые файлы, так как мы напишем внешний отладчик. Эта статья потребует от читателя понимание основ многопоточности.

Предисловие

Изменение .NET метода MSIL кода во время выполнения приложения – это очень круто. Это настолько круто, что можно перехватывать вызовы функций (hooking), сделать защиту своего ПО и другие удивительные вещи. Именно поэтому мне уже давно хотелось это осуществить, но была одна проблема – MSIL код компилируется в машинный код с помощью JIT перед тем, как мы сможем что-либо с этим кодом сделать. А так как .NET CLR не документирована и изменяется от версии к версии, то мы и будем искать стабильный и надёжный путь, независимый от точного расположения адресов в памяти.

В этой статье я покажу вам, как найти подлинный процесс подсистемы Windows, это полезно, например, когда вы пытаетесь получить список активных процессов (заметьте, только процессы, которые работают в подсистеме Windows могут быть найдены таким образом, а кроме подсистемы Windows есть еще подсистемы POSIX и OS/2, которые уже, можно сказать, уже и не поддерживаются), перечисляя структуры CSR_PROCESS, список которых находится в процессе CSRSS.

С появлением в системе управления HP IMC web-сервиса доступа RESTful eAPI, система может теперь не только управлять устройствами, но и быть частью общего комплекса управления мультивендорной средой, обеспечивая следующую ступень к автоматизации и гибкости настройки всей сетевой инфраструктуры.

iMC обеспечивает web сервисы на основе открытой сервис ориентированной архитектуры (SOA). Web сервисы главным образом выполнены через использование следующих методов: REST, SOAP, and XML-RPC. В сравнении с другими двумя методами REST-style функционал прозрачен и прост.

Доступ к iMC RESTful web сервисам может быть получен с помощью следующих Java REST клиентов:

• Apache Commons HTTP Client (3.1)
• Apache HTTP Client (4.x)
• SpringFramework (3.x) RestTemplate
• Jersey Client
• Android SDK

Что нужно проделать для написания клиента, использующего IMC-RS? Следующая секция покажет, как получить доступ к IMC-RS при помощи Java.

Копировать элементы из одного контейнера в другой? Нет ничего проще, универсальный алгоритм помещается в 5 строк:

template<class InputIterator, class OutputIterator>
OutputIterator copy(InputIterator first, InputIterator last, OutputIterator result) {
    while(first != last) *result++ = *first++;
    return result;
}

Возможно вы узнали реализацию std::copy с cplusplus.com. Почему же реализация std::copy из GNU STL занимает 139 строк? Давайте разберемся.

Мне по работе часто приходится сталкиваться с высоконагруженными многопоточными или многопроцессными сервисами (application-, web-, index-server).
Достаточно интересная, но иногда неблагодарная работа — оптимизировать все это хозяйство.
Растущие потребности клиентов часто упираются в невозможность просто заменить железную составляющую системы на более современную, т.к. производительность компьютеров, скорость чтения-записи жестких дисков и сети растут много медленнее запросов клиентов.
Редко помогает увеличение количества нодов кластера (система как правило распределенная).
Чаще приходится запустив профайлер, искать узкие места, лезть в source code и править ляпы, которые оставили коллеги, а иногда и сам, чего греха таить, много лет назад.
Некоторые из проблем, связаных с синхронизацией, я попытаюсь изложить здесь. Это не будет вводный курс по многопоточному программированию — предпологается, что читатель знаком с понятием thread и context switch, и знает для чего нужны mutex, semaphore и т.д.

За счет чего же мы наблюдаем постоянный рост производительности однопоточных программ? В данный момент мы находимся на той ступени развития микропроцессорных технологий, когда прирост скорости работы однопоточных приложений зависит только от памяти. Количество ядер растет, но частота зафиксировалась в пределах 4 ГГц и не дает прироста производительности.

Скорость и частота работы памяти — это то основное за счет чего мы получаем «свой кусок бесплатного торта» (ссылка). Именно поэтому важно использовать память, настолько эффективно, насколько мы можем это делать, а тем более такую быструю как кэш. Для оптимизации программы под конкретный компьютер, полезно знать характеристики кэш-памяти процессора: количество уровней, размер, длину строки. Особенно это важно в высокопроизводительном коде — ядра систем, математические библиотеки.

Как же определить характеристики кэша автоматический? (естественно cpuinfo распарсить не считается, хотя-бы потому-что в конечном итоге мы бы хотели получить алгоритм, который можно без труда реализовать в других ОС. Удобно, не правда ли? ) Именно этим мы сейчас и займемся.

Немного теории

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