• noexcept-ctcheck или несколько простых макросов, чтобы компилятор помогал при написании noexcept кода

      При разработке на C++ время от времени приходится писать код, в котором исключения не должны возникать. Например, когда нам нужно написать не бросающий исключений swap для собственных типов или определить noexcept move-оператор для своего класса, или вручную реализовать нетривиальный деструктор.


      В С++11 в язык был добавлен модификатор noexcept, который позволяет разработчику понять, что из помеченной noexcept-ом функции (или метода) исключения вылететь не могут. Поэтому функции с такой пометкой могут смело использоваться в контекстах, где исключения не должны возникать.


      Например, если у меня есть вот такие типы и функции:


      class first_resource {...};
      class second_resource {...};
      
      void release(first_resource & r) noexcept;
      void close(second_resource & r);

      и есть некий класс resources_owner, который владеет объектами типа first_resource и second_resource:


      class resources_owner {
         first_resource first_resource_;
         second_resource second_resource_;
         ...
      };

      то я могу написать деструктор resources_owner следующим образом:


      resources_owner::~resources_owner() noexcept {
         // Функция release() не бросает исключений, поэтому просто вызываем ее.
         release(first_resource_);
      
         // А вот функция close() может бросать исключения, поэтому
         // обрамляем ее try-catch.
         try{ close(second_resource_); } catch(...) {}
      }

      В каком-то смысле noexcept в C++11 сделал жизнь C++ разработчика легче. Но у текущей реализации noexcept в современном C++ есть одна неприятная сторона...


      Компилятор не помогает контролировать содержимое noexcept функций и методов

      Читать дальше →
      • +10
      • 1.5k
      • 7
    • Усложнение C++ неизбежно. И не только C++

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


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


        Язык программирования — это технологичный продукт, но не все так просто


        Некоторое время назад довелось прочесть интересную книгу «Дилемма инноватора». Там на примерах технологичных продуктов показывается, как возникают новые продукты, которые сперва проигрывают доминирующим сейчас на рынке решениям, а затем кардинальным образом меняют состояние рынка.


        Один из самых ярких примеров: цифровая фотография, которая в 1990-х была вообще никакой, но спустя всего 20 лет привела к краху такого монстра XX-го века, как Kodak (который, кстати говоря, первым и сделал прототип цифровой камеры).


        image
        Читать дальше →
      • RESTinio — это асинхронный HTTP-сервер. Простой пример из практики: отдача большого объема данных в ответ


          Недавно мне довелось поработать над приложением, которое должно было контролировать скорость своих исходящих подключений. Например, подключаясь к одному URL приложение должно было ограничить себя, скажем, 200KiB/sec. А подключаясь к другому URL — всего 30KiB/sec.


          Самым интересным моментом здесь оказалось тестирование этих самых ограничений. Мне потребовался HTTP-сервер, который бы отдавал трафик с какой-то заданной скоростью, например, 512KiB/sec. Тогда бы я мог видеть, действительно ли приложение выдерживает скорость 200KiB/sec или же оно срывается на более высокие скорости.


          Но где взять такой HTTP-сервер?


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


          О том, насколько это было просто и хотелось бы рассказать в статье. Заодно узнать в комментариях, действительно ли это просто или же я сам себя обманываю. В принципе, данную статью можно рассматривать как продолжение предыдущей статьи про RESTinio под названием "RESTinio — это асинхронный HTTP-сервер. Асинхронный". Посему, если кому-то интересно прочитать о реальном, пусть и не очень серьезном применении RESTinio, то милости прошу под кат.

          Читать дальше →
        • A declarative data-processing pipeline on top of actors? Why not?

            Some time ago, in a discussion on one of SObjectizer's releases, we were asked: "Is it possible to make a DSL to describe a data-processing pipeline?" In other words, is it possible to write something like that:


            A | B | C | D


            and get a working pipeline where messages are going from A to B, and then to C, and then to D. With control that B receives exactly that type that A returns. And C receives exactly that type that B returns. And so on.


            It was an interesting task with a surprisingly simple solution. For example, that's how the creation of a pipeline can look like:


            auto pipeline = make_pipeline(env, stage(A) | stage(B) | stage(C) | stage(D));

            Or, in a more complex case (that will be discussed below):


            auto pipeline = make_pipeline( sobj.environment(),
                    stage(validation) | stage(conversion) | broadcast(
                        stage(archiving),
                        stage(distribution),
                        stage(range_checking) | stage(alarm_detector{}) | broadcast(
                            stage(alarm_initiator),
                            stage( []( const alarm_detected & v ) {
                                    alarm_distribution( cerr, v );
                                } )
                            )
                        ) );

            In this article, we'll speak about the implementation of such pipeline DSL. We'll discuss mostly parts related to stage(), broadcast() and operator|() functions with several examples of usage of C++ templates. So I hope it will be interesting even for readers who don't know about SObjectizer (if you never heard of SObjectizer here is an overview of this tool).

            Read more →
          • Just take a look at SObjectizer if you want to use Actors or CSP in your C++ project


              A few words about SObjectizer and its history


              SObjectizer is a rather small C++ framework that simplifies the development of multithreaded applications. SObjectizer allows a developer to use approaches from Actor, Publish-Subscribe and Communicating Sequential Processes (CSP) models. It's an OpenSource project that is distributed under BSD-3-CLAUSE license.


              SObjectizer has a long history. SObjectizer itself was born in 2002 as SObjectizer-4 project. But it was based on ideas from previous SCADA Objectizer that was developed between 1995 and 2000. SObjectizer-4 was open-sourced in 2006, but its evolution was stopped soon after that. A new version of SObjectizer with the name SObjectizer-5 was started in 2010 and was open-sourced in 2013. The evolution of SObjectizer-5 is still in progress and SObjectizer-5 has incorporated many new features since 2013.


              SObjectizer is more or less known in the Russian segment of the Internet, but almost unknown outside of the exUSSR. It's because the SObjectizer was mainly used for local projects in exUSSR-countries and many articles, presentations, and talks about SObjectizer are in Russian.


              A niche for SObjectizer and similar tools


              Multithreading is used in Parallel computing as well as in Concurrent computing. But there is a big difference between Parallel and Concurrent computing. And, as a consequence, there are tools targeted Parallel computing, and there are tools for Concurrent computing, and they are different.

              Read more →
            • Достраиваем в RESTinio четвертый этаж из C++ных шаблонов. Зачем и как?

                RESTinio — это относительно небольшой проект, представляющий из себя встраиваемый в C++приложения асинхронный HTTP-сервер. Его характерной особенностью является широкое, можно сказать, повсеместное применение C++ных шаблонов. Как в реализации, так и в публичном API.


                C++ные шаблоны в RESTinio используются настолько активно, что первая статья, которая рассказывала о RESTinio на Хабре, называлась "Трехэтажные C++ные шаблоны в реализации встраиваемого асинхронного HTTP-сервера с человеческим лицом".


                Трехэтажные шаблоны. И это, в общем-то, была не фигура речи.


                А недавно мы в очередной раз обновили RESTinio и для добавления новой функциональности в версию 0.5.1 пришлось сделать "этажность" шаблонов еще выше. Так что местами C++ные шаблоны в RESTinio уже четырехэтажные.



                И если кому-то интересно зачем нам такое потребовалось и как мы шаблоны использовали, то оставайтесь с нами, под катом будет немного подробностей. Матерые C++ гуру вряд ли найдут для себя что-нибудь новое, а вот менее продвинутые C++ники смогут посмотреть на то, как шаблоны применяются для вставки/изъятия кусков функциональности. Почти что в "дикой природе".

                Читать дальше →
              • SObjectizer-5.6.0: режем по живому, чтобы расти дальше


                  Третьего дня стала доступна новая версия SObjectizer-а: 5.6.0. Ее главная особенность — это отказ от совместимости с предыдущей стабильной веткой 5.5, поступательно развивавшейся на протяжении четырех с половиной лет.


                  Основные принципы работы SObjectizer-5 остались прежними. Сообщения, агенты, кооперации и диспетчеры все еще с нами. Но что-то серьезно изменилось, что-то вообще было выброшено. Поэтому просто взять SO-5.6.0 и перекомпилировать свой код уже не получится. Что-то потребуется переписать. Что-то, возможно, придется перепроектировать.


                  Почему мы несколько лет заботились о совместимости, а потом решились взять и все поломать? И что поломали наиболее основательно?


                  Об этом я и попробую рассказать в данной статье.


                  Зачем вообще потребовалось что-то ломать?


                  Тут как раз все просто.

                  Читать дальше →
                • RESTinio — это асинхронный HTTP-сервер. Асинхронный

                    Пару лет назад мы опубликовали RESTinio — свой небольшой OpenSource C++фреймворк для встраивания HTTP-сервера в C++ приложения. Мегапопулярным за это время RESTinio не стал, но и не потерялся. Кто-то выбирает его за "родную" поддержку Windows, кто-то за какие-то отдельные фичи (вроде поддержки sendfile), кто-то за соотношение возможностей, простоты использования и настраиваемости. Но, думаю, изначально многих RESTinio привлекает вот этим лаконичным "Hello, World"-ом:


                    #include <restinio/all.hpp>
                    int main()
                    {
                        restinio::run(
                            restinio::on_this_thread()
                            .port(8080)
                            .address("localhost")
                            .request_handler([](auto req) {
                                return req->create_response().set_body("Hello, World!").done();
                            }));
                        return 0;
                    }

                    Это, действительно, все, что нужно чтобы запустить HTTP-сервер внутри C++ приложения.


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


                    А раз такой вопрос актуален, то можно еще раз о нем поговорить и привести парочку небольших примеров.

                    Читать дальше →
                  • С сожалением об отсутствии в C++ полноценного static if или…

                      … как наполнить шаблонный класс разным содержимым в зависимости от значений параметров шаблона?


                      Когда-то, уже довольно давно, язык D начали делать как "правильный C++" с учетом накопившегося в C++ опыта. Со временем D стал не менее сложным и более выразительным языком, чем C++. И уже C++ стал подсматривать за D. Например, появившийся в C++17 if constexpr, на мой взгляд, — это прямое заимствование из D, прототипом которому послужил D-шный static if.


                      К моему сожалению, if constexpr в С++ не обладает такой же мощью, как static if в D. Тому есть свои причины, но все-таки бывают случаи, когда остается только пожалеть, что if constexpr в C++ не позволяет управлять наполнением C++ного класса. Об одном из таких случаев и хочется поговорить.


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


                      Задача, которую требуется решить


                      Требуется создать хитрый вариант "умного указателя" для хранения объектов-сообщений. Чтобы можно было написать что-то вроде:

                      Читать дальше →
                    • Немного C++ной шаблонной магии и CRTP для контроля за корректностью действий программиста в компайл-тайм

                        Недавно, работая над новой версией SObjectizer-а, довелось столкнуться задачей контроля в компайл-тайм действий разработчика. Суть была в том, что ранее программист мог делать вызовы вида:


                        receive(from(ch).empty_timeout(150ms), ...);
                        receive(from(ch).handle_n(2).no_wait_on_empty(), ...);
                        receive(from(ch).empty_timeout(2s).extract_n(20).stop_on(...), ...);
                        receive(from(ch).no_wait_on_empty().stop_on(...), ...);

                        Операция receive() требовала набор параметров, для указания которых использовались цепочки методов, вроде показанных выше from(ch).empty_timeout(150ms) или from(ch).handle_n(2).no_wait_on_empty(). При этом вызов методов handle_n()/extract_n(), ограничивающих количество извлекаемых/обрабатываемых сообщений, был необязательным. Поэтому все показанные выше цепочки были корректными.


                        Но в новой версии потребовалось заставить пользователя обязательно явно указывать количество сообщений для извлечения и/или обработки. Т.е. цепочка вида from(ch).empty_timeout(150ms) теперь становилась некорректной. Её следовало заменить на from(ch).handle_all().empty_timeout(150ms).


                        Причем хотелось сделать так, чтобы именно компилятор бил бы программиста по рукам, если программист забыл сделать вызов handle_all(), handle_n() или extract_n().


                        Может ли C++ помочь в этом?


                        Да. И если кому-то интересно как именно, то милости прошу под кат.

                        Читать дальше →
                        • +16
                        • 2.9k
                        • 7
                      • «Современные» обедающие философы на C++ посредством акторов и CSP

                          Некоторое время назад ссылка на статью "Modern dining philosophers" распространилась по ресурсам вроде Reddit и HackerNews. Статья интересная, она показывает несколько решений этой известной задачи, реализованных на современном C++ с использованием task-based подхода. Если кто-то это статью еще не читал, то имеет смысл потратить время и прочесть ее.


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


                          При этом task-based подход не является единственным возможным для решения подобных задач. Почему бы не посмотреть, как задача "обедающих философов" решается посредством моделей Акторов и CSP?


                          Посему попробовал посмотреть и реализовал несколько решений этой задачи как с использованием Акторов, так и с использованием CSP. Код этих решений можно найти в репозитории на BitBucket-е. А под катом пояснения и объяснения, так что кому интересно, милости прошу под кат.

                          Читать дальше →
                        • Как писать unit-тесты для акторов? Подход SObjectizer-а

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

                            В общем, писать многопоточные приложения с использованием акторов легко и приятно. В том числе и потому, что сами акторы пишутся легко и непринужденно. Можно даже сказать, что написание кода актора — это самая простая часть работы. Но вот когда актор написан, то возникает очень хороший вопрос: «Как проверить правильность его работы?»

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

                            Но вот вышла версия 5.5.24, в которой появилась экспериментальная поддержка возможности unit-тестирования акторов. И в данной статье мы попытаемся рассказать о том, что это, как этим пользоваться и с помощью чего это было реализовано.
                            Читать дальше →
                          • Текстовая версия доклада «Actors vs CSP vs Tasks...» с C++ CoreHard Autumn 2018

                              В начале ноября в Минске прошла очередная посвященная языку C++ конференция C++ CoreHard Autumn 2018. На ней был сделан капитанский доклад «Actors vs CSP vs Tasks...», где речь шла о том, как может выглядеть в C++ применение более высокоуровневых, чем «голая многопоточность», моделей конкурентного программирования. Под катом преобразованная в статью версия этого доклада. Причесанная, местами подправленная, местами дополненная.

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

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

                              Примечание: в оригинальной презентации к докладу были обнаружены ошибки и опечатки, поэтому в статье будут использованы слайды из обновленной и отредактированной версии, которую можно найти в Google Slides или на SlideShare.

                              «Голая многопоточноть» — это зло!


                              Начать нужно с многократно повторенной банальности, которая, тем не менее, все еще остается актуальной:
                              Многопоточное программирование на C++ посредством голых нитей, mutex-ов и condition variables – это пот, боль и кровь.
                              Читать дальше →
                            • Четыре года развития SObjectizer-5.5. Как SObjectizer изменился за это время?

                                Первая версия SObjectizer-а в рамках ветки 5.5 вышла чуть больше четырех лет назад — в начале октября 2014-го года. А сегодня увидела свет очередная версия под номером 5.5.23, которая, вполне возможно, закроет историю развития SObjectizer-5.5. По-моему, это отличный повод оглянуться назад и посмотреть, что же было сделано за минувшие четыре года.

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

                                Возможно, кому-то такой рассказ будет интересен с точки зрения археологии. А кого-то, возможно, удержит от такого сомнительного приключения, как разработка собственного акторного фреймворка для C++ ;)
                                Читать дальше →
                              • Новое в SObjectizer-5.5.23: исполнение желаний или ящик Пандоры?



                                  Данная статья является продолжением опубликованной месяц назад статьи-размышлении "Легко ли добавлять новые фичи в старый фреймворк? Муки выбора на примере развития SObjectizer-а". В той статье описывалась задача, которую мы хотели решить в очередной версии SObjectizer-а, рассматривались два подхода к ее решению и перечислялись достоинства и недостатки каждого из подходов.

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

                                  Сегодня же мы поговорим о том, что было сделано, зачем это было сделано, к чему это привело. Если кому-то интересно следить за тем, как развивается один из немногих живых, кросс-платформенных и открытых акторных фреймворков для C++, милости прошу под кат.
                                  Читать дальше →
                                • Легко ли добавлять новые фичи в старый фреймворк? Муки выбора на примере развития SObjectizer-а



                                    Разработка бесплатного фреймворка для нужд разработчиков — это специфическая тема. Если при этом фреймворк живет и развивается довольно долго, то специфики прибавляется. Сегодня я попробую показать это на примере попытки расширить функциональность «акторного» фреймворка для C++ под названием SObjectizer.

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

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

                                    И вот нам, как разработчикам фреймворка, приходится делать выбор в пользу одного или другого решения. Или же нужно признать, что ни одно из них удовлетворительным не является и, поэтому, нужно придумывать что-то другое. Такие решения за время истории SObjectizer-а приходилось принимать неоднократно. Если кому-то интересно почувствовать себя в шкуре разработчика подобного фреймворка, то милости прошу под кат.
                                    Читать дальше →
                                  • Давайте попробуем поговорить про иерархические конечные автоматы вообще и их поддержку в SObjectizer-5 в частности

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

                                      Поэтому в данной статье мы попробуем поговорить о КА, в первую очередь об иерархических конечных автоматах и их продвинутых возможностях. И немного рассказать о поддержке КА в SObjectizer-5, «акторном» фреймворке для C++. Одном из тех двухнескольких, которые открыты, бесплатны, кросс-платформенны, и все еще живы.

                                      Даже если вам не интересен SObjectizer, но вы, скажем, никогда не слышали про иерархические конечные автоматы или о том, насколько полезны такие продвинутые возможности КА, как обработчики входа-выхода для состояний или история состояния, то вам может быть интересно заглянуть под кат и прочесть хотя бы первую часть статьи.
                                      Читать дальше →
                                      • +13
                                      • 3.3k
                                      • 2
                                    • Делаем Shrimp еще полезнее: добавляем перекодирование картинок в другие форматы



                                        С начала 2017-го года наша небольшая команда разрабатывает OpenSource-библиотеку RESTinio для встраивания HTTP-сервера в C++ приложения. К своему большому удивлению мы время от времени получаем вопросы из категории «А для чего может потребоваться встраиваемый HTTP-сервер на C++?» К сожалению, на простые вопросы отвечать сложнее всего. Иногда лучшим ответом является пример кода.

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

                                        Этот демо-проект хорош тем, что в нем, во-первых, требуется интеграция с давным-давно написанным и исправно работающим кодом на C или C++ (в данном случае это ImageMagick). Поэтому должно быть понятно, почему имеет смысл встраивать HTTP-сервер в C++ приложение.

                                        И, во-вторых, в данном случае требуется асинхронная обработка запросов, дабы HTTP-сервер не блокировался пока выполняется масштабирование картинки (а это может занимать сотни миллисекунд или даже секунды). А разработку RESTinio мы затеяли именно потому, что не смогли найти вменяемый C++ный встраиваемый сервер, ориентированный именно на асинхронную обработку запросов.

                                        Работу на Shrimp-ом мы построили итеративным путем: сперва была сделана и описана самая простая версия, которая только масштабировала картинки. Затем мы устранили ряд недочетов первой версии и описали это во второй статье. Наконец дошли руки расширить функциональность Shrimp-а еще раз: добавилось преобразование картинок из одного формата в другой. О том, как это было сделано и пойдет речь в данной статье.
                                        Читать дальше →
                                        • +15
                                        • 2.1k
                                        • 9
                                      • Развиваем Shrimp: контролируем параллельные запросы, логируем через spdlog и еще…



                                          На прошлой неделе мы рассказали про свой небольшой демо-проект Shrimp, который наглядно показывает, как можно использовать C++ные библиотеки RESTinio и SObjectizer в более-менее похожих на реальность условиях. Shrimp — это маленькое приложение на C++17, которое посредством RESTinio принимает HTTP-запросы на масштабирование изображений и обслуживает эти запросы в многопоточном режиме посредством SObjectizer-а и ImageMagick++.

                                          Проект оказался более чем полезным для нас самих. Копилка хотелок для расширения функциональности RESTinio и SObjectizer заметно пополнилась. Кое что уже даже нашло свое воплощение в совсем свежей версии RESTinio-0.4.7. Так что мы решили не останавливаться на самой первой и самой тривиальной версии Shrimp-а, а сделать еще одну-две итераций вокруг этого проекта. Если кому-то интересно что и как мы сделали за это время, милости просим под кат.
                                          В качестве спойлера: речь пойдет о том, как мы избавились от параллельной обработки идентичных запросов, как добавили в Shrimp логирование с помощью отличной библиотеки spdlog, а также сделали команду принудительного сброса кэша трансформированных картинок.
                                          Читать дальше →
                                        • Shrimp: масштабируем и раздаем по HTTP картинки на современном C++ посредством ImageMagic++, SObjectizer и RESTinio



                                            Предисловие


                                            Наша небольшая команда занимается развитием двух OpenSource инструментов для C++разработчиков — акторного фреймворка SObjectizer и встраиваемого HTTP-сервера RESTinio. При этом мы регулярно сталкиваемся с парой нетривиальных вопросов:

                                            • какие фичи добавлять в библиотеку, а какие оставлять «за бортом»?
                                            • как наглядно показывать «идеологически правильные» способы использования библиотеки?

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

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

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

                                            Сегодня мы хотим рассказать как раз об одной такой «небольшой» задачке, в которой естественным образом объединились SObjectizer и RESTinio.

                                            Масштабирование и раздача картинок. Почему именно это?


                                            В качестве небольшой демо-задачи для самих себя мы выбрали HTTP-сервер, который раздает по запросам отмасштабированные картинки. Вы складываете изображения в какой-то каталог, запускаете HTTP-сервер, делаете к нему запрос вида:
                                            Читать дальше →