[prog.c++.flame] Взять бы, да и закрыть Boost...

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

Вот просто взять и закрыть. Что вошло в Boost, то пусть там и остается.

А вот всем остальным нужно учиться жить без Boost-а.

Поскольку языку программирования нужна не одна мегабиблиотека, в которую пытаются впихнуть все. А нормальный. Повторяю, нормальный, Карл!, способ подтаскивания в свой проект сторонних библиотек. Но пока есть Boost, и пока попадание в Boost является целью для многих разработчиков библиотек, эволюция и селекция нормальных способов управления зависимостями в C++ идет черепашьими темпами.

Да и смысл Boost-а в настоящее время от меня ускользает. 17 лет назад Boost был полигоном для обкатки того, что хотелось бы включить в стандарт. Boost.Thread, Boost.SharedPtr, Boost.Optional и все такое. Ну OK, тогда это было актуально, когда работа над стандартами C++ велась не слишком быстро.

Но сейчас-то? Какой смысл в Boost-е кроме как в централизованной сборке относительно небольшого количества C++ных библиотек, которые совместно тестируется перед релизом? Ну кроме протекционизма?

Кстати о протекционизме. Вот есть в Boost-е библиотеки Boost.Test, Boost.Log, Boost.Format. Для которых существуют не менее достойные, мягко говоря, аналоги в виде Catch, Spdlog и Fmtlib. С какой стати старые и неудобные монстры, вроде Boost.Test и Boost.Log, должны иметь преференции в современном мире перед теми библиотеками, которые в Boost не входят? Ведь не так уж и редко от сторонних аналогов люди отказываются потому, что дальше Boost-а и не заглядывают. Но даже если и заглядывают, то иногда предпочитают Boost, потому что Boost к проекту уже подключен, а подтаскивание еще одной библиотеки в C++ный проект -- это боль для многих.

В общем, Карфаген должен быть разрушен Boost сделал свое дело, Boost должен уйти.

PS. Пост написан под влиянием боли, которая появляется, когда в зависимостях кросс-платформенного проекта оказывается достаточно свежая версия Boost-а.

[prog.c++] Если разрабатывать REST-сервисы на C++, то как должен выглядеть "инструмент мечты"?

Допустим, вам нужно разработать RESTful сервис на C++. Не будем сейчас вступать в религиозные споры на тему того, зачем, когда и кому в здравом уме это может потребоваться. Ну мало ли ;) Может нужно выставить REST API для старого легаси-кода, которому 20 лет и который никто с C++ переписывать не будет. Может нужна высокая эффективность и низкое потребление ресурсов. Может нужно сделать это для военки на Эльбрусах какой-то экзотической платформы, для которой нормального качества компиляторы есть только для C и C++. Может еще что-то, включая упоротость и мазохизм :)

Итак, вы стоите перед выбором, как же сделать REST API на C++. В какую сторону вы будете смотреть? Напишете все сами или постараетесь взять что-то готовое?

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

Если будете выбирать согласно своих требований, то что вы в свой список требований включите обязательно? Что будет однозначно положительными факторами в пользу стороннего решения? А что однозначно отрицательным?

Может вы уже используете что-то и вас в этом что-то сильно не устраивает? Что?

Понимаю, что вопросов много. Но почему бы не пофантазировать и не пообщаться о том, как оно должно было бы быть в идеальном мире C++? :)

[prog] Проблема нумерации: so_5_extra-5.5.19-1.0 или so_5_extra-1.0-5.5.19 или...?

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

У нас на финальную стадию подготовки к релизу вышла дополнительная библиотека для SObjectizer-а под названием so_5_extra. Сейчас в нее входят три компонента: однопоточный вариант SObjectizer Environment на базе Asio (немного об этом здесь), готовая реализация round-robin mbox-а и специальная штука под названием shutdowner, которая предназначена для обработки некоторых сценариев завершения больших приложений. Со временем состав so_5_extra будет еще расширяться, но для первого релиза нам показалось достаточно этих трех. Все это уже работает и протестировано, но нужно еще написать какую-то вводно-обзорную документацию.

Неожиданной сложностью оказался выбор системы нумерации версий для so_5_extra. Традиционный semver, вроде so_5_extra-1.0.0, здесь не очень подходит потому, что версии so_5_extra планируется плотно синхронизировать с версиями SObjectizer-а. Поскольку so_5_extra в своей реализации очень активно использует знание того, что и как выполняется в конкретной версии SObjectizer. Поэтому версия so_5_extra-1.0.0, которая была сделана для SObjectizer-5.5.19, не обязательно будет работать с SObjectizer-5.5.18 или SObjectizer-5.5.20. В обратном направлении, кстати, тоже работает. SObjectizer так же допиливается под нужды so_5_extra. Например, вместе с первой версией so_5_extra мы опубликуем и SObjectizer-5.5.19.2, в который добавлено несколько фич для работы so_5_extra.

Поэтому хочется иметь какую-то систему нумерации, в которой номера версий so_5_extra были каким-то боком увязаны друг с другом. Но, при этом, чтобы допускалась некоторая свобода. Например, может быть so_5_extra-1.0.0, которая выпущена для SO-5.5.19.2, но затем появляется SO-5.5.19.3, из-за которой менять номер для so_5_extra не нужно. С другой стороны, может быть so_5_extra-1.0.1, ради которой не нужно менять номер версии SO-5.5.19.2.

В результате я сейчас всерьез рассматриваю следующие варианты системы нумерации:

1. so_5_extra-5.5.19-1.0. С тем, чтобы впоследствии можно было использовать номера вида so_5_extra-5.5.19-1.0.12, so_5_extra-5.5.19-1.2.39, so_5_extra-5.5.20-1.0 и т.д. Тут, правда, возникает вопрос: как между собой соотносятся, скажем so_5_extra-5.5.19-1.2.39 и so_5_extra-5.5.20-1.0.0? На который у меня пока ответа нет;
2. so_5_extra-1.0-5.5.19. С последующим развитием в сторону so_5_extra-1.2.39-5.5.19, so_5_extra-2.0-5.5.19 и т.д.
3. Просто тупо совместить нумерацию so-5 и so_5_extra. Т.е. если есть so-5.5.19.2, то и есть so_5_extra-5.5.19.2. Если есть so_5_extra-5.5.20.34, то есть и so-5.5.20.34. Хотя этот вариант мне нравится меньше всего.

Посему вопрос к читателям: что вас меньше испугает и запутает? so_5_extra-5.5.19-1.0.0 или so_5_extra-1.0.0-5.5.19?