О плюсах плюсов вроде говорили — настоящая кроссплатформенность, скорость запуска (нет JIT и прочего), большая кодовая база.
А вот почему на Java/C#/Dart/etc. — писать проще и комфортнее? Есть ли однозначный ответ?
Можно сказать что из-за управления памятью. Но вроде умные указатели таки можно сказать вопрос решили. Но даже если этот вопрос убрать — то все-равно, как ни крути, а как-то медленнее получается писать (читать) и я затрудняюсь ответить почему так.
Возможная причина, кмк, непростая парадигма времени компиляции. Шаблоны те же бывают трех-четырех и пяти этажные... В может и не в этом дело.
Здравствуйте, Shmj, Вы писали:
S>А вот почему на Java/C#/Dart/etc. — писать проще и комфортнее? Есть ли однозначный ответ.
S>Можно сказать что из-за управления памятью. Но вроде умные указатели таки можно сказать вопрос решили. Но даже если этот вопрос убрать — то все-равно, как ни крути, а как-то медленнее получается и я затрудняюсь ответить почему так.
1. GC. Это самое главное. Ему никакой замены нет. Умные указатели это полная шляпа. Rust ломает мозг. Псевдоумные указатели на счётчиках дают утечки на циклических структурах, хотя по эргономичности они, наверное, идут сразу после GС.
2. Адекватная стандартная библиотека. В С++ она просто максимально мегаужасна. Там просто всё плохо, от начала до конца.
3. IDE. В Java IDE прекрасны. В C++ они ужасны. И это не исправить, это генетическое, из-за сложности языка.
4. Сопутствующий тулинг. В Java про него просто не думаешь. В С++ вечно какой-то гемор. Впрочем допускаю, что тут просто разница в опыте.
5. Простота языка. В Java очень редко возникают ситуации, где хочется навернуть шаблон на шаблон. В С++ — начинаешь проект и сходу начинаешь писать свой класс строки, свой класс массива, свой класс связанного списка (т.к. стандартные убоги, см. выше), и в итоге прошёл месяц, а ты закопался в стандартах и думаешь, как же реализовать какой-нибудь оператор присваивания в execption-safe и thread-safe виде, хотя изначально тебе надо было просто HTTP запрос сделать и распарсить его ответ. С++ просто тебя заваливает какой-то лажей, не имеющей отношения к решаемой задаче.
S>А вот почему на Java/C#/Dart/etc. — писать проще и комфортнее? Есть ли однозначный ответ.
На этих языках программы в большей степени "выполняются слева направо сверху вниз".
Меньше возможностей навертеть умонерастяжимых неотлаживаемых ребусов, которые понимает только их незаменимый автор (а остальные, кому понадобится сопровождать этот код, "пусть много трудятся впустую над их распутыванием, и выглядят тупыми перед начальством").
Строчки-цветочки, шмектор-коллектор, переписать неправильные стандартные контейнеры... Сколько раз это слышал, скучно уже. В твоем гите мухи в полете не дохнут? Все это скорее говорит о том, как ты прогаешь, и о том, что наработанных средств для решения задач из твоей же предметной области на плюсах у тебя просто нет. Ну так не берись на них прогать, делов то...
Здравствуйте, Shmj, Вы писали:
S>А вот почему на Java/C#/Dart/etc. — писать проще и комфортнее? Есть ли однозначный ответ.
Да, есть, C++ это язык с "избыточным" функционалом. Слишком много парадигм требуют более квалифицированных программистов.
На C++ можно писать в стиле простейших скриптов вплоть до одного файла. А можно использовать обобщённое или объектно-ориентированное программирование. И ещё до кучи парадигм, структурное и процедурное. Хочешь модульное, пожалуйста, а не хочешь и не надо.
По алгоритмам так же. Можно использовать голые системные вызовы. А можно воспользоваться кроссплатформенными библиотеками. Можешь писать алгоритмы сам. Можешь воспользоваться готовыми. Хочешь ассемблерную вставку, она есть у меня. Хочешь множественное наследование, ну ты сам так решил.
Из-за этого возникает огромное количество возможных архитектур программ. Программисты с этим не справляются, и вот это уже вопрос по поводу обучения. Иначе говоря лёгкость других языков программирования и якобы сложность C++ это чистейшая иллюзия основанная на привычных для каждого языка методах обучения.
Это не проблема C++, это проблема тех людей у которых от возможностей разбегаются глаза и они начинают творить монстра.
В других языках тебе как бы намекают.
1. Вот у нас есть мощный встроенный фреймворк и он написан по таким вот правилам, и ты пиши так же. 2. Или вот тут все пишут в стиле скриптов, давай не робей, сразу пиши алгоритмы в скриптах.
А C++ тебе говорит, у нас тут миллион и три тележки возможностей, давай же используй, используй их все сразу!!!
Короче, программист C++, я тебя спас и в благородство играть не буду: выполнишь для меня пару заданий – и мы в расчете. Заодно посмотрим, как быстро у тебя башка после амнезии прояснится. А по твоей теме постараюсь разузнать. Хрен его знает, на кой ляд тебе эти парадигмы программирования сдались, но я в чужие дела не лезу, хочешь использовать, значит есть зачем.
- нельзя одной строчкой кода/одной командой подцепить стороннюю библиотеку. В JS/Python/Go и т.д. подключение сторонней библиотеки делается крайне просто и быстро. В плюсах с этим надо помучаться, т.к. нет единого подхода
— стандартная библиотека не настолько проста и удобна, как в других языках. Элементарная работа с файлами, путями; те же контейнеры могли бы быть более простыми в работе (типа как в Qt)
Здравствуйте, Osaka, Вы писали:
O>Меньше возможностей навертеть умонерастяжимых неотлаживаемых ребусов, которые понимает только их незаменимый автор (а остальные, кому понадобится сопровождать этот код, "пусть много трудятся впустую над их распутыванием, и выглядят тупыми перед начальством").
А в каких конкретно особенностях языка это выражается?
Здравствуйте, velkin, Вы писали:
V>На C++ можно писать в стиле простейших скриптов вплоть до одного файла. А можно использовать обобщённое или объектно-ориентированное программирование. И ещё до кучи парадигм, структурное и процедурное. Хочешь модульное, пожалуйста, а не хочешь и не надо.
V>По алгоритмам так же. Можно использовать голые системные вызовы. А можно воспользоваться кроссплатформенными библиотеками. Можешь писать алгоритмы сам. Можешь воспользоваться готовыми. Хочешь ассемблерную вставку, она есть у меня. Хочешь множественное наследование, ну ты сам так решил.
Вроде все это, кроме, разве что, обобщённого — есть и в других языка и погоды не строит. Получается основная фигня — в обобщенном, которого в простых языках нет в явном виде?
Здравствуйте, Shmj, Вы писали:
S>Вроде все это, кроме, разве что, обобщённого — есть и в других языка и погоды не строит. Получается основная фигня — в обобщенном, которого в простых языках нет в явном виде?
Проблема в неуправляемом обучении. Возьми Java и C#.NET, там есть готовые фреймворки из комплекта. А это считай готовая архитектура подражая которой можешь написать что-то не слишком убогое. Или у скриптовых языков пишешь в самом простом стиле и все довольны.
А что произойдёт при обучении C++, особенно при самостоятельном обучении. Человек открывает книги, спецификации, а там объектно-ориентированное программирование, но вообще без его правильного использования в виде готовых фреймворков.
А стандартная библиотека шаблонов C++ никак не научит писать код лучше. Обобщённое программирование по сути это уже следующий этап, когда из функций и классов генерируется код. И те кто это изобрели вначале программировали в Си стиле, это потом они уже дошли до новых понятий.
У меня сотни книг по программированию, большинство по C++. Там новичок не то, что не разберётся, он будет двигаться в другую сторону, изучать не алгоритмизацию, а абстракции.
Просто если тебе так уж интересно различия языков, возьми: Rosetta Code: Задачи.
abstract class Class1
{
public abstract void method1();
public int method2()
{
return 0;
}
}
C++
class Abs
{
public:
virtual int method1(double value) = 0;
virtual int add(int a, int b)
{
return a+b;
}
};
Java
abstract class Example {
protected int methodB(int value) {
return value + 100;
}
public abstract int methodC(int valueA, int valueB);
}
Примеры не эквивалентны, но видно же, что языки не различаются по сложности на порядки и даже на один порядок. Какие-нибудь мелкие проблемы раздуваются до невиданных высот. Ту же утечку памяти можно отследить с помощью Valgrind. В GNU/Linux он как и отладчик сразу встроен в Qt Creator, но надо же об этом постоянно писать.
Потому я говорю, что с моей точки зрения это всё иллюзия про то, что там что-то простое, а здесь что-то сложное. А политическая повесточка это уже другое дело. Я уже написал про это статью, Прикладные антисанкционные языки программирования, и даже обсудил.
Что ещё можно сказать? Хочешь используй то, а хочешь это. И да, новичков когда они только начинают что-то изучать пытаются подловить на простых лозунгах. Типа это просто, а это ух как сложно. А когда вскроется обман простым обзором кода, то уже уйдут годы на изучения нужных пропагандистам технологий.
Меня всегда прикалывали гуглы и майкрософты, которые построили свой бизнес на C/C++, но сами что только людям не втюхивали.
Здравствуйте, Shmj, Вы писали:
S>А вот почему на Java/C#/Dart/etc. — писать проще и комфортнее? Есть ли однозначный ответ?
Потому что C++ имеет больше возможностей делать одно и то же. Причем часть способов устарел, часть тормозит, а часть ведет к UB. И заранее не скажешь в какую категорию попадает то, что пишешь сейчас.
Сможете сходу сказать какой правильный способ инициализации объектов и какой конструктор для этого надо написать?
S>Можно сказать что из-за управления памятью. Но вроде умные указатели таки можно сказать вопрос решили. Но даже если этот вопрос убрать — то все-равно, как ни крути, а как-то медленнее получается писать (читать) и я затрудняюсь ответить почему так.
Ну конечно не решили, скорее даже ухудшили. Если в голом C можно было передать указатель на структуру и копию структуры, то в C++ можно передать: копию объекта, указатель, ссылку, smart_ptr, ссылку на smart_ptr, указатель на smart_ptr, rvalue ссылку, rvalue ссылку на smart_ptr. Ничего не забыл?
И, кстати, ссылки, как и указатели не безопасны. Подробнее в видео https://youtu.be/qeiRGbYCD-0
S>Возможная причина, кмк, непростая парадигма времени компиляции. Шаблоны те же бывают трех-четырех и пяти этажные... В может и не в этом дело.
Прикладному программисту почти не надо писать шаблоны, а если надо, то спасает typedef. А вот при ошибке использования шаблонных функций и объектов даже из STL текст ошибки получается ну очень невнятный, даже сейчас в 2023, что усложняет поиск ошибок.
а) язык реально очень большой.
б) стандартная библиотека напротив сильно маленькая.
Например, до сих пор в стандартной библиотеке нет ничего про сетевое программирование
Это когда практически все системы стали с сетевым взаимодействием.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>>Например, до сих пор в стандартной библиотеке нет ничего про сетевое программирование S>И славатехоспади!
Не...
В каждой новой конторе что-то не стандартное.
Да и много чего приходится стороннего брать.
А в Go — из коробки и работает везде одинаково.
На мой взгляд это Go+++, а не C++ S>Достаточно истории с добавлением в стандарт std::unordered_map.
Ну, забыли...
В запарке при сдаче релиза и такое бывает
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>В каждой новой конторе что-то не стандартное.
Это либо следствие древнего происхождения (и тогда это просто так не переписать), либо следствие специфических задач, под которые пришлось делать свой инструмент, возможно, заточенный не только под задачу, но и под конкретную систему (и тогда это точно на что-то из stdlib не переписать).
LVV>А в Go — из коробки и работает везде одинаково.
Одинаково тормознуто? То-то на пике хайпа вокруг Rust-а появлялись статьи о том, как узкие места Go на Rust-е расшивают.
LVV>Ну, забыли... LVV>В запарке при сдаче релиза и такое бывает
Скорее всего, там была не запарка, а сознательное решение обеспечить сохранность итераторов при модификации, чтобы std::unordered_map мог быть прямой заменой std::map. В результате убили главное преимущество хэш-таблиц и получили рекомендацию не использовать std::unordered_map там, где требуется производительность.
Заиметь в стандарте какую-то реализацию reactor-а или proactor-а для сетевого IO, для которого будет аналогичная рекомендация "не использовать там, где требуется производительность"... Ну такое себе.
В прочем, пока еще есть шансы, что Networking TS следом за Executors TS до стандарта доедут. Не в C++23, так в C++26, ну или в C++29
Здравствуйте, LaptevVV, Вы писали:
LVV>а) язык реально очень большой.
Тут да. И еще такая особенность — язык очень символьный.
Вот в паскале комменты блочные обозначались символами {}. И представьте — чел. привыкает что в {} написано что-то не важное, т.е. то что вообще не исполняется — а тут ему нужно на эти ранее малозначимые символы сконцентрировать все внимание.
А так же контекст символов. Вот звездочка — это или умножение или декларация указателя или же разыменование. Это очень очень сложно удержать в голове и парсить, практически головоломка.
Не говорю уже про шаблоны шаблонов шаблонов шаблонов.
LVV>б) стандартная библиотека напротив сильно маленькая. LVV>Например, до сих пор в стандартной библиотеке нет ничего про сетевое программирование LVV>Это когда практически все системы стали с сетевым взаимодействием.
А вот ни такая уж и маленькая — хрен запомнишь. Целые книги по ней. Сетевого программирования нет, а овердофига других вещей есть.
