Продолжаем перевод серии статей об обработки исключений в С++

1 часть
3 часть

C++ exceptions под капотом: милая персональность

Наша поездка в удивительном путешествии изучения работы исключений еще далека от конца, нам еще предстоит изучить что-то называемое "call frame information", помогающая библиотеке Unwind делать разворачивание стэка, а так же что компилятор пишет в чем-то, называемом LSDA, в которой определяется, какие ошибки метод может обрабатывать. А так же мы уже узнали, что большинство магии происходит в персональной функции, которую мы пока еще не видели в действии. Давайте резюмируем, что мы уже знаем о пробросе и отлове ошибок (или, точнее, что мы уже знаем о том, как брошенное будет перехвачено):

• компилятор транслирует throw объявление в пару cxa_allocate_exception/xca_throw
• __cxa_allocate_exception создает исключение в памяти
• __cxa_throw запускает работу разворачивания и передает исключение в низко-уровневую библиотеку разворачивания, вызывая _Unwind_RaiseException
• Разворачивание стэка использует CFI, чтобы узнать, какая сейчас функция в стеке
• Каждая функция имеет LSDA, добавляя что-то, называемое .gcc_except_table
• Разворачивание вызывает персональную функцию с текущим фреймом стэка и LSDA, которая должна продолжить разворачивать стэк, если текущая функция не имеет обработчиков исключения данного типа.

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

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

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

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

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

В предыдущих частях (часть 1, часть 2, часть 3, часть 4, часть 5) были рассмотрены принципы и механизмы libuniset2, на примере сферической задачки по управлению. Осталось показать, что не вошло в поле нашего зрения… Тех, кто ещё не устал, прошу…

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

Привет всем. Я хочу рассказать вот о чём… Недели две назад впервые понадобилось работать с GUI под С++ и, погуглив малость, я решил использовать Qt. Его все жутко хвалили, да и вообще на первый взгляд выглядел он весьма достойно.

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

Добавлено: На основе комментариев добрых людей была сделана правка, повествующая о том, как можно обойтись без MOC и без костыликов вообще.

В предыдущих частях (часть 1, часть 2, часть 3, часть 4) было описано создание двух процессов имитатора и процесса управления и предварительная наладка. А теперь я хотел рассказать о написании функциональных тестов и предназначенного специально для этого средства под названием uniset2-testsuite.

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

Библиотека SFML предоставляет простой интерфейс для различных компонентов вашего компьютера, чтобы облегчить разработку игр и мультимедийных приложений. Она состоит из пяти модулей: system, window, graphics, audio и network.

Используя SFML, ваше приложение может быть скомпилировано и запущено на наиболее распространенных платформах: Windows, Linux, Mac OS X(планируется поддержка Android и IOS).

Предварительно скомпилированные SDK для вашей ОС доступны на странице загрузки.

SFML официально поддерживает C и .NET. Также, благодаря своему активному сообществу, она доступна на многих других языках, таких как Java, Ruby, Python, Go и др.

Виртуальные машины — важный инструмент в арсенале разработчика программного обеспечения. Мой интерес к коду VirtualBox вызван личным использованием этого продукта для проверки открытых проектов, а также для других разных задач, связанных с использованием нескольких операционных систем. Первая проверка этого проекта состоялась в 2014 году, тогда описание около 50 ошибок едва уместилось в двух статьях. C выходом Windows 10 и VirtualBox 5.0.XX, на мой взгляд, стабильность работы программы заметно ухудшилась. Поэтому я решил проверить проект ещё раз.

В предыдущих частях (часть 1, часть 2, часть 3) было описано создание двух процессов: имитатора и процесса управления… Теперь же настало время наладки.

При устройстве на работу программистом столкнулся с интересной задачей следующего содержания:

«Напишите программу, которая выводит на экран числа от 1 до 100. При этом вместо чисел, кратных трем, программа должна выводить слово Fizz, а вместо чисел, кратных пяти — слово Buzz. Если число кратно пятнадцати, то программа должна выводить слово FizzBuzz. Задача может показаться очевидной, но нужно получить наиболее простое и красивое решение.»

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

В предыдущих частях (часть 1 и часть 2) я описал создание проекта и привёл пример создания имитатора… Теперь же реализуем собственно алгоритм управления…

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

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

В качестве вычислительного ресурса используется облако Azure. Пользователи могут запускать вычислительные задачи, написанные с помощью С++ (с поддержкой OpenMP), R, Python, Octave, Scilab, Java, Julia, OpenFOAM, GROMACS, Blender на серверах с количеством ядер от 1 до 32 и оперативной памятью до 448 ГБ.

Среди нововведений можно отметить следующие:

В предыдущей статье я закончил на создании и конфигурировании имитатора. Теперь рассмотрим как его запустить…

Когда-то давным-давно… Мной была написана статья «Знакомство с libuniset — библиотекой для создания АСУ», были планы по написанию продолжения, но не сложилось. С тех пор, библиотека значительно «подросла» и даже уже вышла версия 2.0, в которой появилось много новых возможностей: удалённый просмотр логов и программных переменных, поддержка различных полезных и не очень протоколов и баз, есть даже «time-machine», но об этом если до этого дойдёт…

Вообщем я собрался силами и решил, что лучше всё это «один раз увидеть» на конкретном примере.

Поэтому, кому ещё интересно, прошу.

Помимо вполне понятной официальной документации (Chromium Wiki), существуют и статьи о том, как получить исходный код и собрать проект Chromium (например).

Я же хотел рассказать о том, как на основе этого кода можно создавать приложения на C++, способные компилироваться и выполняться на нескольких операционных системах и архитектурах. Конечно, для этой цели уже существуют библиотеки, такие как Qt и boost. Но именно поэтому данная статья относится к разделу 'ненормальное программирование', ведь никто всерьез не рассматривает код Chromium как основу для кроссплатформенного приложения.

Здравствуйте, меня зовут Дмитрий. Я занимаюсь созданием компьютерных игр на Unreal Engine в качестве хобби. Итак, сегодня я продолжу создание системы расстановки объектов. После того, как я её сделал я подумал, что добавление окна пред просмотра позволит ускорить процесс расстановки объектов. Об этом я сегодня и расскажу.

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

Под термином библиотека стандартных шаблонов (STL, Standard Template Library) понимают набор интерфейсов и компонентов, первоначально разработанных Александром Степановым, Менг Ли и другими сотрудниками AT&T Bell Laboratories и Hewlett-Packard Research Laboratories в начале 90-х годов (хотя и позже ещё весьма многие приложили руку к тому, что стало на сегодня стандартным компонентом C++). Далее библиотека STL перешла в собственность компании SGI, а также была включена как компонент в набор библиотек Boost. И наконец библиотека STL вошла в стандарты C++ 1998 и 2003 годов (ISO/IEC 14882:1998 и ISO/IEC 14882:2003) и с тех пор считается одной из составных частей стандартной библиотек C++.

Стандарт не называет эту часть библиотеки STL, но эту хронологию хорошо бы учитывать, разбираясь с какой версией компилятора, языка и литературы вы имеете дело — в процессе сокращения HP STL до размеров, подходящих для стандартизации, часть алгоритмов и функторов выпали из состава библиотеки, а кое-что, со временем, и добавляется (например, расширение набора переопределенных прототипов некоторых методов контейнеров). По тексту будет использоваться традиционное название STL только чтобы было ясно какую часть стандартной библиотеки C++ мы имеем в виду.

Недавно Россию посетила группа экспертов С++, участвующих в работе комитета по стандартизации. 25 февраля они участвовали в Q&A сессии, организованной Яндексом, а после выступали на конференции С++ Russia 2016. Одним из них был Гор Нишанов, автор предложения о включении C#-подобных сопрограмм (те которые async/await) в стандарт С++17. Ранее Гор выступал на CppCon 2015 с докладом "С++ Сопрограммы — Абстракция с отрицательным оверхедом". Такая возможность структурировать асинхронный код выглядит привлекательно, Гор в докладе убедительно показывает, что количество кода сокращается, а скорость работы возрастает по сравнению с «рукописными» State Machine. Кроме того, это одно из самых больших потенциальных изменений в следующем стандарте и привлекает к себе внимание. Судя по публикациям, proposal получил значительное одобрение и комитет склоняется к включению в стандарт.

После этого я был весьма удивлен, когда загуглив упомянутый proposal P0057, получил в выдаче встречный документ "Coroutines belong in a TS", который подвергает предлагаемую реализацию сопрограмм жесткой и весьма эмоциональной критике и требует не включать в С++17, а отложить для «обкатки» в Technical Specification. Отмечу, что не являюсь сторонником этих возражений, а приглашаю интересующихся к обсуждению, насколько обоснованны перечисленные претензии и все ли так плохо. Под катом «выжимка» из документа с небольшими комментариями.