[prog.flame] Java-программисты боятся, что в Java добавят ключевое слово var

Все-таки люди, программирующие на Java, имеют особый склад ума (что, в принципе, ожидаемо, учитывая свойства этого языка программирования). Иначе сложно объяснить волнения, вызванные намерениями добавить в Java ключевое слово var (например, вот статья с попытками рассмотреть доводы "за" и "против" на Хабре и уже не маленькое обсуждение на LOR-е).

Странные люди. Смотреть нужно в первую очередь на то, что можно получить от автоматического вывода типа локальной переменной. Насколько я помню, именно необходимость такого вывода стала причиной добавления var-ов в C#, т.к. без этого реализация и использование LINQ вряд ли были бы возможны. Да и в C++11, после добавления в язык variadic templates и lambdas без auto уже никуда. Ну вот серьезно, сейчас в C++ я могу написать вот так:

std::thread first; std::thread second; std::thread third; auto thr_joiner = so_5::auto_join(first, second, third);

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

std::thread first; std::thread second; std::thread third; so_5::threads_auto_joiner<3> thr_joiner = so_5::auto_join(first, second, third);

Еще веселее дела обстоят с лямбда-функциями, для которых тип генерируется самим компиляторам и который неизвестен программисту. Ключевое слово auto позволяет вот так:

std::FILE * f = std::fopen(file_name, "r"); if( f ) {    auto f_closer = at_scope_exit([f]{ std::fclose(f); });    ... }

А если бы его не было, как бы пришлось извращаться? Писать что-то вроде:

std::FILE * f = std::fopen(file_name, "r"); if( f ) {    at_exit_t< std::function<void()> > f_closer = at_scope_exit([f]{ std::fclose(f); });    ... }

Как говорится, нет уж, спасибо ;)

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

Так что, на мой взгляд, очень странные обсуждения ведутся в стане Java-программистов. Впрочем, там язык настолько убог, что может var просто поздно добавлять... :)

---

Касательно auto в C++. До тех пор, пока не работаешь плотно с навороченными шаблонными конструкциями, к auto относишься настороженно. Ведь, действительно, код, в котором сплошные auto, прочитать сложнее, чем код со всеми аннотациями типов. Однако, даже если речь идет о более-менее простых ситуациях, без шаблонных наворотов, то оказывается, что auto может повысить качество и безопасность кода. Взять, скажем, совсем свежий пример:

char *path_name(const struct name_path *path, const char *name) {         const struct name_path *p;         char *n, *m;         int nlen = strlen(name);         int len = nlen + 1;

Ведь будь он написан вот в таком виде:

char *path_name(const struct name_path *path, const char *name) {         const struct name_path *p;         char *n, *m;         auto nlen = strlen(name);         auto len = nlen + 1;

Менее понятным он бы не стал. А вот надежнее -- наверняка.

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

[prog.c++11] Дальнейшая диверсификация SObjectizer?

С момента появления mchain-ов в версии 5.5.13 возможности SObjectizer-а по поддержке CSP-like concurrency потихонечку расширяются. Так, в грядущей версии 5.5.16 mchain-ы станут полноценными MPMC-каналами (т.е. сразу несколько нитей смогут читать сообщения из mchain-а). Плюс, конечно же, функция select, которая позволяет выбирать сообщения сразу из нескольких mchain-ов.

В связи с этим уже неправильно позиционировать SObjectizer как только лишь actor framework. Т.к. кроме actor model из коробки уже имеется поддержка и CSP channels.

А раз так, может пойти и еще дальше? И добавить в SObjectizer поддержку цепочек задач? Что-то вроде:

void initiate_image_processing(so_5::environment_t & env, image_params params) {    // Готовим цепочку задач и привязываем ее к уже созданному    // thread_pool-диспетчеру с именем "tasks_pool".    schedule( env,       so_5::disp::thread_pool::create_disp_binder("tasks_pool", ...),       make_task( env, [params]() -> so_5::task< loaded_image > {          ... // Какие-то действия по загрузке картинки.          return loaded_image{ ... };       })       .then([]( loaded_image & img ) -> so_5::task< prepared_image > {          ... // Какая-то нехилая обработка.          return prepared_image{ ... };       })       .then([]( prepared_image & img ) -> so_5::task< converted_image > {          ... // Какая-то еще более нехилая обработка.          return converted_image{ ... };       })       .then([params]( converted_image & img ) {          ... // Ну совсем замороченная обработка.          so_5::send< transformed_image >(params.dest(), ...);       }) ); }

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

Понятное дело, что глубоко в эту тему я не копал. Но, думается, можно сделать что-то вроде Data Flow и Dependency Graphs из Intel-овской Threading Building Blocks или Task Parallelism из Microsoft-овской PPL. Вопрос только в том, нужно/интересно ли это кому-нибудь?

PS. Возможно, все это будет логичным продолжением прототипа для реактивного программирования средствами SO-5, только в другом синтаксисе.

[prog.c++11] Первый релиз-кандидат SObjectizer-5.5.16

Зафиксирован первый релиз-кандидат версии 5.5.16 проекта SObjectizer. Версия 5.5.16, в основном, расширяет возможности mchain-ов: теперь один и тот же mchain можно спокойно использовать в нескольких receive на разных нитях (в предшествующих версиях это могло привести к засыпанию некоторых нитей, если они вызвали receive когда mchain был пуст). Реализована функция select, которая позволяет ожидать сообщения сразу из нескольких mchain-ов. Плюс еще несколько мелочей.

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

Взять 5.5.16-rc1 можно из репозитория (либо Svn на SourceForge, либо Git на GitHub).

Соответственно, если у кого-то будут замечания/предложения по текущей реализации, то не стесняемся, высказываем. Есть возможность вносить изменения до релиза. После релиза будет сложнее, т.к. сохранение совместимости между версиями внутри ветки 5.5 -- это одна и важных целей.