Здравствуйте, smeeld, Вы писали:
S>У нас на Go платформу пилят. Bigdata платфoрму. На том же этаже квартируется компания, которая занимается AI. Делают свою Алису. Пишут всё на python, PHP, JS, и среди них нет ни одного С++-ника (но все МГУ-шники).
Все так. А ты, коллега, судя по всему из компании на ме начинающейся, на ру оканчивающейся
Здравствуйте, DiPaolo, Вы писали:
S>>> Да что там акторы да каналы, куда большая банальщина типа сети или работы с файлами в C++ только-только появилась и, как я полагаю, в большинстве проектов просто не доступна так как сидят на старых стандартах с одной стороны, и у всех есть свой любимый велосипед с другой стороны.
DP>В Qt все это давно есть, пользоваться удобно, понятно и приятно.
Здравствуйте, so5team, Вы писали:
S>Несколько примеров реального фидбэка от попыток продвигать простую и лаконичную работу с акторами/CSP в C++:
S>
S> ой, у вас тут современный C++, лямбды повсюду, шаблоны на каждом шагу, перегрузка операторов... Это все слишком сложно. Вот был бы интерфейс в стиле "Си с классами"... S> ой, у вас тут современный C++, лямбды повсюду, шаблоны на каждом шагу... А у нас компилятор только для C++98 и в обозримом времени мы даже на C++11 перейти не сможем. Вот если бы вы поддерживали C++98... S> у вас используются исключения и RTTI, у нас эти фичи в проекте запрещены; S> предоставляете ли вы real-time гарантии? А нам они нужны, у нас real-time система. S>
S>Решение любой из вышеперечисленных проблем автоматически делает работу с акторами/CSP ни капли не лаконичной. Да и о простоте речь вряд ли будет идти.
Вот это исчерпывающий ответ почему С++ отмирает — усидеть на двух стульях нельзя. Я в кулуарах людям из комитета задавал вопрос как они позиционируют С++, мне все отвечали, что С++ — язык общего назначения, попытка донести мысль, что на данный момент языков общего назначения куда проще С++ и с инфраструктурой до которой С++ как до Китая, при этом с производительностью достаточной, что шансов С++ не оставляет, поэтому надо определится с нишей и ее занять, понимания неизменно не находили.
S>Тогда как в Erlang/Go/Rust эти проблемы вообще никого не волнуют.
Именно.
S>Почитаешь таких замшелых разработчиков и остается только удивляться, как в языке вообще появились те же constexpr, if constexpr, fold expression или CTAD.
Это все конечно прекрасно, но нужно оно в первую очередь разработчикам библиотек, а на обычного разработчика давно положен болт. Каналы, корутины, модули, идет 2019 год.
Здравствуйте, Denis Ivlev, Вы писали:
DI>Я в кулуарах людям из комитета задавал вопрос как они позиционируют С++, мне все отвечали, что С++ — язык общего назначения
Как раз очень широкое применение C++, от встраиваемых систем и hard real-time систем, до сервер-сайда, HPC, GUI, игр, мобильных приложений и пр., лучше всего свидетельствует о том, что C++ язык общего назначения.
Поинт был в том, что в C++ из-за его широкого применения в самых разнообразных условиях невозможно создать простые и удобные инструменты, которые бы подходили всем.
Поэтому высказывания о том, что в C++ нет таких же удобных каналов, как в Go, в реальности разбиваются о то, что подобные каналы в C++ будут использовать хорошо, если 30% разработчиков. А остальные не смогут этого сделать по совершенно разным причинам. В том числе и идеологическим. В том числе и потому, что "у нас на проекте много низкоквалифицированных программистов, поэтому им нельзя давать ничего со сложной шаблонной машинерией внутри".
DI>Это все конечно прекрасно, но нужно оно в первую очередь разработчикам библиотек, а на обычного разработчика давно положен болт. Каналы, корутины, модули, идет 2019 год.
Ну вот и хэш-таблицы, и регулярные выражения в стандартной библиотеке C++ присутствуют с 2011-го. Но критики в их адрес больше, чем хотелось бы. Или вот в C++20 завезут fmtlib и все равно будет полно возгласов, что мой любимый домашний велосипед лучше и быстрее.
Это особенность мира C++: чтобы не завезли в стандарт, все это будет раскритиковано.
Здравствуйте, CreatorCray, Вы писали:
CC>Я хз за что и где тебя заминусовали но например в этом топике тема сто раз пережёванная, думается что просто уже не интересно что либо разъяснять.
Твое сообщение было бы гораздо легче понять, если бы в нем были все необходимые знаки припенания...
Здравствуйте, DiPaolo, Вы писали:
DP>В Qt все это давно есть, пользоваться удобно, понятно и приятно.
Есть, но, к сожалению, это "велосипед" т.к. не часть языка (пишу с Qt если что). И стоит дорого, особенно для железок.
Здравствуйте, smeeld, Вы писали:
S>У нас на Go платформу пилят. Bigdata платфoрму. С нуля. Вместо существующей на C++, монстробразной и уродливой, обросшей легаси, и работающей с большим скрипом, нескончаемым потоком дефектов на каждый релиз, случающийся раз в два года. Предложение писать новую платформу на С++ никто не поддержал, включая старых бородатых C++-ников.
Вроде ты тут приводил пример своего С++ кода не так давно Оно многое объясняет.
Здравствуйте, so5team, Вы писали:
S> у вас используются исключения и RTTI, у нас эти фичи в проекте запрещены;
Хе, у нас как раз RTTI выключено.
И причина вполне прозаичная — текущая реализация RTTI это дыра в защите.
Заказывали как-то анализ защиты приложения.
Нанятый ревёрсер принес практически идентичный нашему исходный код программы, только что не с комментариями.
Т.е. взломать программу с включенный RTTI это вообще не проблема. Для коробочных продуктов это жЫрный минус.
А так ваш SObjectizer очень хорошо бы подошел к некоторым нашим задачам.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Skorodum, Вы писали:
DP>>В Qt все это давно есть, пользоваться удобно, понятно и приятно. S>Есть, но, к сожалению, это "велосипед" т.к. не часть языка (пишу с Qt если что). И стоит дорого, особенно для железок.
имхо, он и не должен быть частью языка.
в языке нужны низкоуровневые вещи типа boost.context, и стандартный механизм установки зависимых пакетов из репозитория.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Denis Ivlev, Вы писали:
DI>>Я в кулуарах людям из комитета задавал вопрос как они позиционируют С++, мне все отвечали, что С++ — язык общего назначения
S>Как раз очень широкое применение C++, от встраиваемых систем и hard real-time систем, до сервер-сайда, HPC, GUI, игр, мобильных приложений и пр., лучше всего свидетельствует о том, что C++ язык общего назначения.
Из всего перечисленного списка только hard real-time и местами HPC остался за плюсами в новых проектах.
Все остальное, если это не legacy-пилится уже на чем угодно, только не на плюсах. А если кто и начал пилить на плюсах-безумству храбрых поем мы песню! Похоронную
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>А так ваш SObjectizer очень хорошо бы подошел к некоторым нашим задачам.
В том-то и дело, что использование RTTI позволяет снять с разработчика заботу об идентификации типов сообщений. Т.е. как раз сделать работу с акторами простой и лаконичной.
Можно и без RTTI, например, заставить разработчика специализировать специальный шаблон под его собственные типы сообщений, что-то вроде:
namespace Application {
class FirstMessageType { ... };
class SecondMessageType { ... };
class ThirdMessageType { ... };
}
namespace so_5 {
template<>
struct message_identity<Application::FirstMessageType> : public simple_identifier<10203> {};
template<>
struct message_identity<Application::SecondMessageType> : public simple_identifier<10204> {};
template<>
struct message_identity<Application::ThirdMessageType> : public simple_identifier<10205> {};
}
Но тогда количество работы у пользователя прибавится. Да и когда есть большое количество сообщений в разных модулях, можно нарваться на пересечение айдишников.
Мы могли бы в so-5 альтернативный механизм идентификации поддержать, но так уж получается, что все, что в so-5 попадает, затем поддерживается и развивается за наш собственный счет. Поэтому мы просто не можем позволить себе впихнуть в проект все, что могло бы кому-то потребоваться.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Т.е. взломать программу с включенный RTTI это вообще не проблема. Для коробочных продуктов это жЫрный минус.
А что вы такое пишете, что это стало проблемой? Впервые виде что этим кто-то в мире коробочного софта заморачивается.
Здравствуйте, night beast, Вы писали:
NB>имхо, он и не должен быть частью языка. в языке нужны низкоуровневые вещи типа boost.context,
Речь про такие вещи как поддержка сети, файловой системы, время и т.п. Сейчас это часть С++, в то время как это часть Qt уже 20+ лет.
NB>и стандартный механизм установки зависимых пакетов из репозитория.
Я бы сказал это главная проблема С++ на сегодня. И в обозримом будущем она не решится. Другая большая проблема это системы сборки, но тут CMake стал почти стандартом (хоть я его и не очень люблю, но задачу решить можно).
Здравствуйте, so5team, Вы писали:
S>свидетельствует о том, что C++ язык общего назначения.
Верно.
S>Поэтому высказывания о том, что в C++ нет таких же удобных каналов, как в Go, в реальности разбиваются о то, что подобные каналы в C++ будут использовать хорошо, если 30% разработчиков.
А что, остальные просят такие же "каналы как в go"?
S>Или вот в C++20 завезут fmtlib и все равно будет полно возгласов, что мой любимый домашний велосипед лучше и быстрее.
Ну так а что делать если он и лучше и быстрее? Тут уже сравнивали.
Здравствуйте, CreatorCray, Вы писали:
S>>Поэтому высказывания о том, что в C++ нет таких же удобных каналов, как в Go, в реальности разбиваются о то, что подобные каналы в C++ будут использовать хорошо, если 30% разработчиков. CC>А что, остальные просят такие же "каналы как в go"?
Остальные просят "такие же, но с перламутровыми пуговицами". В лучшем случае. Самые замшелые вообще говорят, что диды без каналов писали и мы будем.
S>>Или вот в C++20 завезут fmtlib и все равно будет полно возгласов, что мой любимый домашний велосипед лучше и быстрее. CC>Ну так а что делать если он и лучше и быстрее? Тут уже сравнивали.
Просто использовать то, что лучше подходит под конкретный пример. И спокойно принимать то, что в стандартную библиотеку C++ входят вещи, которые устраивают далеко не всех (как по своему дизайну, так и по производительности).
Здравствуйте, CreatorCray, Вы писали:
S>>ой, у вас тут современный C++, лямбды повсюду, шаблоны на каждом шагу, перегрузка операторов...
CC>А реально ли надо ли все эти навороты?
Как правило, лямбды и шаблоны позволяют писать меньше (иногда сильно меньше) и получать более безопасный код. Иногда они позволяют сделать то, что по другому вообще непонятно как сделать.
Но если у компании бюджет резиновый и куча спецов в штате, то можно и не заморачиваться.
Здравствуйте, so5team, Вы писали:
S>Несколько примеров реального фидбэка от попыток продвигать простую и лаконичную работу с акторами/CSP в C++:
S>
S> ой, у вас тут современный C++, лямбды повсюду, шаблоны на каждом шагу, перегрузка операторов... Это все слишком сложно. Вот был бы интерфейс в стиле "Си с классами"... S>
Шаблоны, перегрузка операторов были в C++98, лямбды — мелочь. У вас что, древний C++? Сейчас 2019, почему мало умных указателей и move-семантика не на каждом шагу??
Если серьезно, то претензии к C++ (у меня лично) не к перегрузке операторов, которая там давно, а к более новым фичам: move-семантике, указателям<> вместо сборки мусора.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, lpd, Вы писали:
lpd>>Сейчас 2019, почему мало умных указателей и move-семантика не на каждом шагу??
S>Мало где?
Если серьезно, то претензии к C++ (у меня лично) не к перегрузке операторов, которая там давно, а к более новым фичам: move-семантике, указателям<> вместо сборки мусора. Но ты в исходном посте не смог обойтись без гиперболизации и упомянул перегрузку операторов и шаблоны.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
