[prog.c++] Разбор asfikon's "C vs C++". Часть 5.

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

Приступим.

[prog.c++] Разбор asfikon's "C vs C++". Часть 4.

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

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

Итак, приступим.

[prog] Вопрос по организации связей между узлами/процессами на базе открытых стандартов и/или протоколов

Допустим, что у нас есть десяток-полтора узлов внутри локальной сети. На каждом узле работает свой набор прикладных процессов. Разных процессов. Процессы должны обмениваться между собой данными. Например, процесс A должен отослать сообщение процессу B, процесс B -- процессу C, процесс C -- процессу D, процесс D -- процессам A и B. При этом процессы A и B могут работать на одном узле, процессы C и D -- на разных узлах. Взаимодействие может быть как в режиме fire-and-forget, так и в режиме request-reply. Но больше, все-таки, в режиме fire-and-forget. Поток сообщений более-менее приличный: от нескольких десятков тысяч сообщений, до сотни тысяч. Размер сообщений относительно небольшой, порядка 1.5-2 килобайт.

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

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

Поэтому можно смотреть и в сторону peer-to-peer взаимодействия. Например, на базе модного нынче REST-а. Получится, что в каждом процессе открывается HTTP-вход, на который и приходят REST-запросы. Процесс A делает REST-запрос к процессу B, процесс B делает запрос к процессу C и т.д. Все знают URL-ы процессов, с которыми взаимодействуют и могут сделать запрос напрямую. Что хорошо.

Проблема с REST-ом в том, что он отлично ложится на взаимодействие request-reply. А вот для fire-and-forget уже не так хорошо: зачем, спрашивается, делать отдельный HTTP POST, пусть даже и по keep-alive соединению, если ответ нам все равно не нужен (как и подтверждение доставки)? Понятное дело, что современные HTTP-сервера способны обрабатывать сотни тысяч запросов на одном ядре. Но все-таки...

Как я понимаю, под такие задачи хорошо ложится, например, система взаимодействия процессов в Erlang-е. Там процесс A знает PID процесса B и просто отсылает B сообщения. Если A и B оказались на одной ноде в рамках одной Erlang VM, то для доставки сообщения вообще никаких внешних IPC не будет задействовано. Проблема в том, что это Erlang-овая кухня, которая не подойдет, если нужно организовать интероперабильность процессов, реализованных на разных языках программирования (например, C++, Java, Python).

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

PS. Вопрос вызван не какой-то конкретной задачей, а попыткой осмыслить подходы к реализации нескольких систем, о которых довелось узнать.

[prog.c++] Разбор asfikon's "C vs C++". Часть 3.

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

[life.cinema] Очередной кинообзор (2016/11)

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

28 панфиловцев (2016). Нужно просто идти и смотреть. Очень достойное кино.

Коллектор (2016). Мне понравилось.

Антропоид (Anthropoid, 2016). К западным фильмам на тему Второй Мировой отношусь с настороженностью. Но этот, как мне показалось, вполне достойный фильм.

Морган (Morgan, 2016). Неплохо. Отдельным актерам за их отличную игру я бы вообще сказал отдельное спасибо.

Сноуден (Snowden, 2016). Оливер Стоун, конечно, мастер. Хотя сама история мне лично была не очень интересна, но не отдать дань уважения мастерству режиссера не могу.

Парни со стволами (War Dogs, 2016). Прикольный фильм. Прикольный в том плане, что сопереживания нет вообще ни к одному герою.

Ледокол (2016). Ждал большего.

Налетчики (Braqueurs, 2015). Не шедевр. Но если французское криминальное кино нравится, то можно посмотреть. Просто чтобы отдохнуть от голливудской стилистики.

Чудо на Гудзоне (Sully, 2016). Снято, конечно, мастерски. Но смотреть не очень интересно, потому что "фильм немного предсказуем" (с). Понятно, чем все в итоге закончится, отчего происходящее на экране не цепляет.

Зачинщики (Masterminds, 2016). Нормально. Но мне показалось, что фильм больше держится на обаянии нескольких актеров, чем на сюжете или шутках.

Бен-Гур (Ben-Hur, 2016). Красочно. Но настолько все шаблонно, линейно и предсказуемо, что это убивает все остальные впечатления от фильма.

С вещами на вылет (Débarquement immédiat!, 2016). Незамысловатая французская комедия. В меру тупая. Местами смешная. Как по мне, так не достаточно смешная для комедии.

Деньги (Money, 2016). Так себе. Можно и не смотреть.

[prog.c++] Разбор asfikon's "C vs C++". Часть 2.

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

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

[prog.c++] Разбор asfikon's "C vs C++". Часть 1.

Итак, поскольку на удивление большое количество желающих захотело послушать разбор тезисов статьи ув.тов.asfikon-а "Почему не лишено смысла писать код на C, а не на C++", то начнем выполнять обещание. Для того, чтобы не было завышенных ожиданий, сразу обозначу рамки, в которых будет вестись повествование. Посты с разбором "C vs C++" будут представлять из себя цитаты из оной статьи с моими комментариями о том, что в данной цитате представляет ценность, а что можно смело отправлять в /dev/null. Такой формат предполагался мной изначально. Приношу свои извинения, если кто-то ждал чего-то сильно другого. Впрочем, в комментариях можно оставлять свои соображения о том, какие темы вы бы хотели увидеть более раскрытыми. Может быть со временем получится дойти и до них.

Disclaimer. Есть у меня подозрение, что по большей части придется повторять скучные, банальные и давно известные вещи. Но, похоже "вот и выросло поколение"... Так что без скучных банальностей не обойтись.

Прежде чем перейти к конкретным цитатам, нужно обозначить важный момент, который позволит лучше понять, почему статьи, подобные разбираемой здесь "C vs C++", некорректны в принципе, безотносительно элементов бреда, спекуляций, подтасовок и передергиваний внутри.