Тема модулей и менеджеров пакетов стабильно обсасывается в комментариях — однако крайне редко мелькает в самих публикациях.
А чему тут мелькать? Работа вокруг Modules TS активно идет. Экспериментальную поддержку модулей делают в VC++, clang и GCC. В инструменте для сборки проектов build2 даже реализовали поддержку проектов с C++ными модулями. В общем, работа кипит. Просто ее результаты пока промежуточные и не видны широкой публике.
С менеджерами зависимостей сейчас вообще активная движуха. Такой еще никогда не было в мире C++. Проблема только в том, что не понятно, кто победит :)
Можно ещё вспомнить — пусть и не совсем по теме — пакетные менеджеры Linux.
Как по мне, так это одна из основных причин, по которым штатного менеджера зависимостей для C++ пока нет: огромное количество C++ников разрабатывает код исключительно под Unix-ы и принципиально не желает пользоваться чем-то отличным от штатных пакетных менеджеров их любимых дистрибутивов. И их не волнуют, что есть другие дистрибутивы с другими менеджерами. И уж тем более их не волнуют другие ОС.
Однако С++11 де юре вышел шесть лет назад. Для индустрии это громадный срок. И с тех пор подвижки как-то забуксовали.
Для индустрии шесть лет — это не так уж и много. Даже если сравнивать с возрастом самого С++. Есть куча проектов, которые даже не начинали на C++11 переводить. И, подозреваю, часть из них так и не переведут.
Кроме того, что значит «забуксовали»? Стандарты стали выходить каждые 3 года. Такого в мире C++ еще никогда не было. Но, что еще более важно, начиная с C++14 стала происходить совсем уникальная штука: поддержка нового стандарта практически сразу была доступна в мейнстримовых компиляторах к моменту публикации официального стандарта. VC++ здесь, конечно, был позади GCC и clang, но уже для C++17 обещает серьезно подтянуться.
Из-за того, что обсасывают в основном всякий сахар и введение классов из boost в std.
Ну вот даже тут, в комментариях уже прозвучала мысль о том, что variadic templates в С++ — это всего лишь синтаксический сахар. Возможно, эту мысль распространяют мегагуру, которые и на C++98 с Boost.Preprocessor в обнимку могли генерировать имитацию шаблонов с переменным количеством параметров. Но вот для простых смертных variadic templates стали тем, что перевело использование таких шаблонов из области высокой теории в область обыденной практики. Аналогично и с лямбдами: кто-то мог написать свой Boost.Lambda и получал от этого кайф, кто-то мог использовать Boost.Lambda и мог думать, что в языке лямбды уже есть. А для кого-то лямбды, которые можно просто брать и использовать, появились только с C++11.
Что до переноса классов из Boost-а в stdlib, то одна из задач stdlib — это предоставление словаря, который могут использовать разработчики сторонних библиотек/компонентов. Чтобы если в библиотеке A создается умный указатель на хэш-таблицу, а в библиотеке B этот указатель используется, программистам не приходилось делать конвертеры из типов библиотеки A в типы библиотеки B (а для С++98 это приходилось делать постоянно). Так что это хорошо, что список типов в stdlib постоянно расширяется и туда попадает то, что уже было проверено на практике.
тут не очень ясно выразился — надеюсь, понятно что я имею в виду
Не понятно.
Вещами, работающими не на ублажение тонких нужд и ленивостей прожжённых пользователей (подчеркну — именно тонких нужд, вроде того же оператора spaceship), а на снижение порога вхождения в экосистему.
По моему опыту, как раз то, что добавили в C++11, самым значительным образом упростило вход в язык программирования.
Что до экосистемы в целом, в том числе до пакетного менеджера, то здесь возможности коммитета ограничены в принципе. Добавим сюда еще и то, что передача развития C++ под работу коммитета произошла очень давно (начало работы коммитета — это 1989-1990-й годы). Тогда такой проблемы не существовало в принципе. И нужно было увидеть, как развиваются другие языки и экосистемы, чтобы осознать важность build tool-ов и package manager-ов. И как раз в этом направлении в C++ движуха сейчас активна как никогда. Возможно, даже коммитет начнет в этом направлении что-то делать.
А вообще: язык развивается за счет своего коммьюнити. Если вам лично нужно что-то, то вы сами можете предложить то, что вам нужно. Если вы этого не хотите/не можете сделать, то, поскольку язык развивается сообществом, вы будете пользоваться тем, что предложили и продвинули другие.
Переносить тонны кода с C++98 на C++11/14/17 тоже не все торопятся. Это же не означает, что не нужно развивать C++, выпускать C++17 и разрабатывать C++20.
При появлении де-юре (да и даже де-факто, но признанного большинством) инструмента для управления зависимостями, процесс адаптации под него обязательно пойдет. Какая-то часть старого кода, естественно, никуда не денется. Но вот новый код будут делать уже с расчетом на него.
Тоже самое и системами сборки. Вот становится CMake де-факто стандартом и те проекты, которые развиваются, волей-неволей, но вынуждены либо переходить на CMake, либо добавлять какую-то поддержку для него (например, FindFoo.cmake-файлы).
Я так понимаю, что нет выбора: либо тратим силы на рефлексию, либо на графику. Это все продвигают разные люди и в разных подкомитетах. Поэтому, даже если приостановить работы по предложению по графике, работа по предложению по рефлексии от этого не ускорится.
Грустить из-за чего? Тут когда из C++14 в C++11 возвращаться приходится, то уже неприятно, хотя C++14 — это совсем небольшой шаг вперед в сравнении с C++11. А уж когда нужно в C++98 окунуться, так вообще как будто в каменный век возвращаешься.
Не тем козыряют, как по мне. Совсем не тем, чем следовало бы.
Да, было такое мнение. Вопрос потому и возник, чтобы узнать, а не поменялось ли оно со временем.
Ибо складывается ощущение, что C++-комьюнити само выбирает тот же CMake и ничего хорошего в этом нет :(
Плюс есть такой фактор, что когда люди говорят про модули, которые ожидаются в C++, то у многих складывается ощущение, что с пришествием модулей наступит такое же благоденствие, как в каких-нибудь языках с поддержкой модулей, вроде D или Rust-а, где сам компилятор может разобраться в каком порядке что компилировать. С большой долей вероятности в C++ это будет не так. Если только коммитет на озадачиться тем, чтобы у языка была своя де-юре стандартная система сборки.
STL — он же большой. Какие проблемы при отсутствии исключений вы ожидаете при использовании, скажем, std::find, std::count_if, std::transform, std::copy и др.?
А вот такой вопрос, не очень связанный с содержимым статьи, но связанный с развитием C++: а на заседаниях комитета всплывают вопросы отсутствия в C++ де-факто стандартных средств управления зависимостями и/или средств сборки C++ проектов?
Ну вот в том же Rust-е есть Cargo, которая снимает изрядную часть головной боли с растоманов. В C++ же все, такое ощущение, осталось неизменным с середины 80-х годов. Каждый волен извращаться как хочет. В итоге систем сборки как грязи, на любой вкус, что особенно доставляет, когда в одном проекте нужно объединить библиотеки, использующие разные системы.
Понятное дело, что стандарт C++ — он совершенно не про то, и в стандарте не будет прописываться какая-то система сборки. Но хотя бы эта проблема затрагивается в кулуарах?
Ну я смотрю на это так: если после прочтения статей у многих читателей остается непонимание того, зачем это нужно, где, когда и как это использовать, то это недоработка автора статьи. И тут либо ты находишь возможность разъяснить людям свой подход, либо миришься с тем, что твой подход не понимают и не используют.
Понятное дело, что на более подробное описание требуется много сил и времени. Но что ж поделать-то, продвигать «в народ» что-либо всегда сложно.
Как по мне, там не рассказано. Ты там просто говоришь, что можно сделать репликацию объектов и она в коде будет выглядеть вот так. Но что за репликация, какие к ней требования? Как приложение, в котором репликация требуется, должно реагировать на ошибки?
Т.е. хотелось бы видеть не абстрактную репликацию в вакууме, а более конкретное описание того, что нужно было сделать, как было сделано, почему было сделано именно так. Если будут показаны примеры других подходов, чтобы можно было наглядно сравнить, это было бы вообще здорово.
Тут надо смотреть на характеристику того или иного способа синхронизации.
Не, речь не про то. Вот когда человек видит что-то вроде foo.deferCall(bla-bla-bla), то он может предположить, что за этим скрывается какая-то непростая машинерия. А вот когда это выглядит как foo.call(bla-bla-bla), то догадаться о хитром поведении вызова не просто.
В целом, исходя из опыта могу сказать, что лучше написать меньше кода, чем больше.
Ок. Принято.
Субъектор появился в результате решения практической задачи про реплицированный объект.
Ну вот и надо бы рассказать про эту задачу, уверяю, далеко не все занимаются на C++ репликацией объектов по сети.
Статья большая и, хотя написана тщательно, воспринимается непросто. Возможно, она бы заходила лучше, если бы была разбита на несколько статей поменьше, в которые были бы включены примеры использования различных концепций. В текущем же своем виде она требует еще, как минимум, одной статьи, в которой будет разобран какой-то пример из реальной жизни (или с претензией на оную). Типа: вот традиционный подход и вот какой код вот с какими недостатками. А вот подход на субъекторах и вот как он устраняет эти недостатки.
Пока таких примеров нет, сложно судить о достоинствах предложенной модели. Да и прикидывать ее на задачи, с которыми сам имеешь дело, не так-то просто :(
Чисто с точки зрения здравого смысла возникает несколько вопросов:
— как программисту прикидывать, к каким накладным расходам приводит используемая им (или его коллегами) кухня? Например, написали некий класс Foo, обернули его в адаптер, потом накрутили вокруг него еще субъекторов. Как понять, насколько дорогим будет вызов Foo::bar?
— насколько просто будет работать с кодом, в котором Foo::bar может приостанавливать текущую короутину, запихивать функтор в канал, из которого кто-то что-то вычитает на другой рабочей нити, начнет обработку, телепортируется куда-то и т.д.? При том, что изменение одного слова в определении субъектора для Foo может кардинально поменять способ выполнения Foo::bar. Т.е. речь о том, что C++ и так ругают за то, что код на C++ отличается неочевидностью, здесь же неочевидность становится главной движущей силой.
Понятно, что ответить на эти вопросы без какого-то опыта использования твоих субъекторов невозможно, нужно брать и пробовать. Но, к сожалению, из статей не складывается пока чего-то такого, чтобы вызвало желания взять и попробовать :(
PS. Отрадно, что разговоры в кулуарах конференции не прошли даром и появилось упоминание Симулы.
Ровно до тех пор, пока не придется использовать printf в обобщенном коде. Или до тех пор, пока не придется использовать printf для вывода в определенный пользователем поток данных.
Для тех, кто исходит на известную субстанцию от iostreams, уже давно есть fmtlib. Которая, среди прочего, позволяет работать с пользовательскими типами, для которых определены операторы сдвига именно в std::ostream.
С менеджерами зависимостей сейчас вообще активная движуха. Такой еще никогда не было в мире C++. Проблема только в том, что не понятно, кто победит :)
Как по мне, так это одна из основных причин, по которым штатного менеджера зависимостей для C++ пока нет: огромное количество C++ников разрабатывает код исключительно под Unix-ы и принципиально не желает пользоваться чем-то отличным от штатных пакетных менеджеров их любимых дистрибутивов. И их не волнуют, что есть другие дистрибутивы с другими менеджерами. И уж тем более их не волнуют другие ОС.
Для индустрии шесть лет — это не так уж и много. Даже если сравнивать с возрастом самого С++. Есть куча проектов, которые даже не начинали на C++11 переводить. И, подозреваю, часть из них так и не переведут.
Кроме того, что значит «забуксовали»? Стандарты стали выходить каждые 3 года. Такого в мире C++ еще никогда не было. Но, что еще более важно, начиная с C++14 стала происходить совсем уникальная штука: поддержка нового стандарта практически сразу была доступна в мейнстримовых компиляторах к моменту публикации официального стандарта. VC++ здесь, конечно, был позади GCC и clang, но уже для C++17 обещает серьезно подтянуться.
Что до переноса классов из Boost-а в stdlib, то одна из задач stdlib — это предоставление словаря, который могут использовать разработчики сторонних библиотек/компонентов. Чтобы если в библиотеке A создается умный указатель на хэш-таблицу, а в библиотеке B этот указатель используется, программистам не приходилось делать конвертеры из типов библиотеки A в типы библиотеки B (а для С++98 это приходилось делать постоянно). Так что это хорошо, что список типов в stdlib постоянно расширяется и туда попадает то, что уже было проверено на практике.
Не понятно.
По моему опыту, как раз то, что добавили в C++11, самым значительным образом упростило вход в язык программирования.
Что до экосистемы в целом, в том числе до пакетного менеджера, то здесь возможности коммитета ограничены в принципе. Добавим сюда еще и то, что передача развития C++ под работу коммитета произошла очень давно (начало работы коммитета — это 1989-1990-й годы). Тогда такой проблемы не существовало в принципе. И нужно было увидеть, как развиваются другие языки и экосистемы, чтобы осознать важность build tool-ов и package manager-ов. И как раз в этом направлении в C++ движуха сейчас активна как никогда. Возможно, даже коммитет начнет в этом направлении что-то делать.
А вообще: язык развивается за счет своего коммьюнити. Если вам лично нужно что-то, то вы сами можете предложить то, что вам нужно. Если вы этого не хотите/не можете сделать, то, поскольку язык развивается сообществом, вы будете пользоваться тем, что предложили и продвинули другие.
При появлении де-юре (да и даже де-факто, но признанного большинством) инструмента для управления зависимостями, процесс адаптации под него обязательно пойдет. Какая-то часть старого кода, естественно, никуда не денется. Но вот новый код будут делать уже с расчетом на него.
Тоже самое и системами сборки. Вот становится CMake де-факто стандартом и те проекты, которые развиваются, волей-неволей, но вынуждены либо переходить на CMake, либо добавлять какую-то поддержку для него (например, FindFoo.cmake-файлы).
А чем следовало бы?
Ибо складывается ощущение, что C++-комьюнити само выбирает тот же CMake и ничего хорошего в этом нет :(
Плюс есть такой фактор, что когда люди говорят про модули, которые ожидаются в C++, то у многих складывается ощущение, что с пришествием модулей наступит такое же благоденствие, как в каких-нибудь языках с поддержкой модулей, вроде D или Rust-а, где сам компилятор может разобраться в каком порядке что компилировать. С большой долей вероятности в C++ это будет не так. Если только коммитет на озадачиться тем, чтобы у языка была своя де-юре стандартная система сборки.
Ну вот в том же Rust-е есть Cargo, которая снимает изрядную часть головной боли с растоманов. В C++ же все, такое ощущение, осталось неизменным с середины 80-х годов. Каждый волен извращаться как хочет. В итоге систем сборки как грязи, на любой вкус, что особенно доставляет, когда в одном проекте нужно объединить библиотеки, использующие разные системы.
Понятное дело, что стандарт C++ — он совершенно не про то, и в стандарте не будет прописываться какая-то система сборки. Но хотя бы эта проблема затрагивается в кулуарах?
Понятное дело, что на более подробное описание требуется много сил и времени. Но что ж поделать-то, продвигать «в народ» что-либо всегда сложно.
Т.е. хотелось бы видеть не абстрактную репликацию в вакууме, а более конкретное описание того, что нужно было сделать, как было сделано, почему было сделано именно так. Если будут показаны примеры других подходов, чтобы можно было наглядно сравнить, это было бы вообще здорово.
Ок. Принято.
Ну вот и надо бы рассказать про эту задачу, уверяю, далеко не все занимаются на C++ репликацией объектов по сети.
Пока таких примеров нет, сложно судить о достоинствах предложенной модели. Да и прикидывать ее на задачи, с которыми сам имеешь дело, не так-то просто :(
Чисто с точки зрения здравого смысла возникает несколько вопросов:
— как программисту прикидывать, к каким накладным расходам приводит используемая им (или его коллегами) кухня? Например, написали некий класс Foo, обернули его в адаптер, потом накрутили вокруг него еще субъекторов. Как понять, насколько дорогим будет вызов Foo::bar?
— насколько просто будет работать с кодом, в котором Foo::bar может приостанавливать текущую короутину, запихивать функтор в канал, из которого кто-то что-то вычитает на другой рабочей нити, начнет обработку, телепортируется куда-то и т.д.? При том, что изменение одного слова в определении субъектора для Foo может кардинально поменять способ выполнения Foo::bar. Т.е. речь о том, что C++ и так ругают за то, что код на C++ отличается неочевидностью, здесь же неочевидность становится главной движущей силой.
Понятно, что ответить на эти вопросы без какого-то опыта использования твоих субъекторов невозможно, нужно брать и пробовать. Но, к сожалению, из статей не складывается пока чего-то такого, чтобы вызвало желания взять и попробовать :(
PS. Отрадно, что разговоры в кулуарах конференции не прошли даром и появилось упоминание Симулы.
Для тех, кто исходит на известную субстанцию от iostreams, уже давно есть fmtlib. Которая, среди прочего, позволяет работать с пользовательскими типами, для которых определены операторы сдвига именно в std::ostream.