[prog.c++] Теперь и SObjectizer, и RESTinio перечислены в списке Awesome C++

В общем-то мелочь (на самом деле нет), а очень приятно: теперь и SObjectizer, и RESTinio перечислены в важном для C++сообщества списке Awesome C++.

Для нас, как разработчиков SObjectizer и RESTinio, это важно потому, что в мире C++ люди нередко начинают поиск подходящих для себя инструментов именно с Awesome C++. В этом смысле Awesome C++ -- это нечто вроде "желтых страниц". И теперь оба наших основных OpenSource продукта на этих "желтых страницах" перечислены.

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

---

Как обычно добавлю, что мы очень внимательно относимся ко всем пожеланиям и предложениям наших пользователей. Поэтому если вам чего-то не хватает в SObjectizer/so5extra, RESTinio или json_dto, то дайте нам знать. Постараемся учесть ваше мнение.

Так же, если у кого-то есть сложности в освоении и/или использовании SObjectizer и RESTinio, то не стесняйтесь, спрашивайте. Обязательно поможем. И еще с большим энтузиазмом поможем вам, если вы решите заказать у нас разработку, в которой будут использованы SObjectizer или RESTinio ;)

[prog.c++.fantasy] А что, если кто-то возьмет и форкнет C++?

И будет развивать свой диалект независимо от комитета. Причем вменяемый диалект, с преферансом и куртизанками прямо сейчас, а не после принятия C++26 или C++29?

Звучит вроде бы дико. Но вот мне давеча попалась ссылка на экспериментальный язык Circle. Это форк C++17 с дополнительными возможностями по метапрограммированию, но не только. Поскольку сейчас в C++ мне больше всего не хватает паттерн-матчинга для удобной и надежной работы с optional, variant и expected, то я пробежался по описанию того, что в Circle сделано в плане поддержки паттерн-матчинга.

И знаете что? Выглядит впечатляюще.

Вот пример:

#include <cstdio> int main() {   struct foo_t {     int x, y, z;   };   foo_t obj { 3, 4, 5 };   int Z = 6;   @match(obj) {     // Test an expression against the initializer.     [_, _, 3]    => printf(".z is 3\n");  // structured binding     [  .z: 4]    => printf(".z is 4\n");  // designated binding     // Is Z a test/expression or a binding? If the clause fails, it's got to     // be a test.     [_, _, Z]    => printf("Z must be a binding\n");     _            => printf("Z must be an expression\n");   };   return 0; }

И вот какая мысль внезапно посетила мою голову: а вот что, если автора Circle возьмет "под крыло" какой-нибудь крупный игрок на рынке? Типа Facebook-а, Amazon-а, Bloomberg-а или IBM... И проект превратится из усилий энтузиаста-одиночки во вполне себе живой OpenSource продукт с солидной финансовой поддержкой за плечами.

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

Но вот если форк обещает совместимость с C++17 (т.е. старые кодовые базы на него перетащить не проблема) и, при этом, более оперативное и гладкое развитие в будущем? Развитие под управлением "мягкого диктатора", а не в результате компромиссов комитета? Когда вещи, типа метапрограммирования, паттерн-матчинга и дешевых исключений в нем появляются с темпом в 6-9 месяцев, а не спустя 4-5-6 лет обсуждений в комитете?

Лично я сильно сомневаюсь, что найдется кто-то, кто вложится в поддержку Circle. Но, думаю, если бы такой нашелся, то перспективы бы открылись интересные.

[prog.c++] По поводу стенаний на счет сложности выразительного C++ кода

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

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

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

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

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

Можно сказать, что на собственной шкуре проверил историю, которую когда-то рассказывал Максим Янченко (aka jazzer с RSDN), про быструю и дешевую реализацию парсеров на Boost.Spirit.

---

Какова мораль?

Переусложнить можно все что угодно.

Но фичи C++ действительно дают возможность писать меньше, а результат получать качественно.

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