Здравствуйте, vsb, Вы писали:

vsb>2. Адекватная стандартная библиотека. В С++ она просто максимально мегаужасна. Там просто всё плохо, от начала до конца.
Это субъективно (точнее — из-за отсутствия опыта работы с STL).

vsb>3. IDE. В Java IDE прекрасны. В C++ они ужасны. И это не исправить, это генетическое, из-за сложности языка.
Дело привычки — от MS Visual Studio до Qt Creator — все они не хуже того же Eclipse или IDEA

vsb>5. Простота языка.
Тут соглашусь — Java проще, но C++ значительно универсальнее

vsb>В С++ — начинаешь проект и сходу начинаешь писать свой класс строки, свой класс массива, свой класс связанного списка...
Откройте для себя книгу Н. Джосаттиса "Стандартная библиотека C++"

Здравствуйте, LaptevVV, Вы писали:

LVV>а) язык реально очень большой.
LVV>б) стандартная библиотека напротив сильно маленькая.
LVV>Например, до сих пор в стандартной библиотеке нет ничего про сетевое программирование

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

Здравствуйте, CreatorCray, Вы писали:

CC>Никогда не понимал чего все так дрочат вприсядку на стандартную либу.
CC>Возможно меня опыт системщика приучил

Да, это профдеформация.

На C++ все еще делают приложения в стиле "быстренько собрать прототип, посмотреть что получится, а затем уже доводить до ума". И акцент ставиться на "быстренько собрать", а не на какие-то другие факторы (типа ресурсоемкости, производительности, надежности). Причем еще и делают это люди, которым следовало бы руки основательно так вправить перед тем, как до C++ допускать (а еще бывают персонажи вроде ТС-а).

В таких условиях наличие готового "искаропки" перевешивает все остальное.

Се ля ви.

PS. Почему при таких вводных выбирают именно C++ -- это отдельный вопрос. Иногда потому, что уже есть какой-то кусок функциональности (например, анализ видео) вокруг которого нужно что-то собрать. Т.к. кусок уже на C++, то проще продолжать на C++, чем оборачивать это в какой-нибудь условный Python.

Здравствуйте, Shmj, Вы писали:

S>Возможная причина, кмк, непростая парадигма времени компиляции. Шаблоны те же бывают трех-четырех и пяти этажные... В может и не в этом дело.
S>Как вы думаете?

С++ требует довольно большого времени на вхождение. При прочих равных, раза в 2-3 дольше. Причин много

1. область применения — требует бОльше знаний
2. огромное количество механик в С++, которые большей частью низкоуровневые
3. отдельная проблема это темплейты — сам по себе полноценный язык
4. проектов, где только хороший С++, ничтожное количество. Типичный код это С++ пополам с Си. Может это мне так везёт, не знаю.
5. последствия ошибок достаточно разрушительные в силу отсутствия механизмов изоляции
6. ручная работа с памятью, многозадачностью итд итд

LVV>>б) стандартная библиотека напротив сильно маленькая.
LVV>>Например, до сих пор в стандартной библиотеке нет ничего про сетевое программирование
LVV>>Это когда практически все системы стали с сетевым взаимодействием.
S>А вот ни такая уж и маленькая — хрен запомнишь. Целые книги по ней. Сетевого программирования нет, а овердофига других вещей есть.
Маленькая
Сравни с Java/C#/Go
Очень многих вещей, которые там есть, в С++ нет.

Здравствуйте, AlexGin, Вы писали:

AG>Это субъективно (точнее — из-за отсутствия опыта работы с STL).

Это от наличия опыта. И наличия опыта работы с библиотеками в других языках. Кстати STL далеко не самое ужасное, что есть в C++. Больше всего меня ужасает ввод-вывод. Это же надо догадаться было — перегрузить операторы битового сдвига. Какая-то шизофрения.

vsb>>В С++ — начинаешь проект и сходу начинаешь писать свой класс строки, свой класс массива, свой класс связанного списка...
AG>Откройте для себя книгу Н. Джосаттиса "Стандартная библиотека C++"

Если мне не изменяет память, я эту книгу читал году в 2005.

Здравствуйте, vsb, Вы писали:

vsb>Это же надо догадаться было — перегрузить операторы битового сдвига. Какая-то шизофрения.

По тем временам, когда в наличии был только Си-шный printf и в языке даже на шаблоны еще намека не было, это был прям таки прорыв.

Собственно, на фоне того, как определять собственные formatter-ы для fmtlib, operator<< для вывода собственного типа до сих по выглядит /мега/удобно.

vsb>>>В С++ — начинаешь проект и сходу начинаешь писать свой класс строки, свой класс массива, свой класс связанного списка...

Я еще могу понять когда пишут собственный интрузивный список если в проект еще не затянули условный Boost. Но строки и массивы в XXI-ом веке для каких целей сами делают?

Здравствуйте, Shmj, Вы писали:

S>О плюсах плюсов вроде говорили — настоящая кроссплатформенность, скорость запуска (нет JIT и прочего), большая кодовая база.

S>А вот почему на Java/C#/Dart/etc. — писать проще и комфортнее? Есть ли однозначный ответ?

Да. Потому что кресты это только про язык. а перечисленное это фрэймворки.
Но! Есть адекватная замена крестам https://codeberg.org/kiesel-js/kiesel
zig run core.zig

И ВОТ https://bun.sh
https://github.com/lassade/c2z

Здравствуйте, so5team, Вы писали:

S>Я еще могу понять когда пишут собственный интрузивный список если в проект еще не затянули условный Boost. Но строки и массивы в XXI-ом веке для каких целей сами делают?

Например чтобы использовать человеческий UTF-8. А не непойми что.

Здравствуйте, vsb, Вы писали:

S>>Я еще могу понять когда пишут собственный интрузивный список если в проект еще не затянули условный Boost. Но строки и массивы в XXI-ом веке для каких целей сами делают?

vsb>Например чтобы использовать человеческий UTF-8. А не непойми что.

Ну это строки. А массивы-то зачем?

PS. Неужели проще самому бабахаться с UTF-8, нежели воспользоваться ICU?

Здравствуйте, so5team, Вы писали:

S>>>Я еще могу понять когда пишут собственный интрузивный список если в проект еще не затянули условный Boost. Но строки и массивы в XXI-ом веке для каких целей сами делают?

vsb>>Например чтобы использовать человеческий UTF-8. А не непойми что.

S>Ну это строки. А массивы-то зачем?

Уже не помню.

S>PS. Неужели проще самому бабахаться с UTF-8, нежели воспользоваться ICU?

Не пользовался им. Это же что-то большое на мегабайты? Мне от строк нужна итерация по кодепоинтам. Всякие заумности обычно не нужны. UTF-8 достаточно простой формат и реализуется в несколько десятков строк кода. Если там какие-нибудь сортировки по национальным символам будут нужны, видимо да, ICU нужен будет. А там свой класс строк есть?

Здравствуйте, vsb, Вы писали:

S>>Ну это строки. А массивы-то зачем?

vsb>Уже не помню.

Тогда это похоже на "для красного словца"

S>>PS. Неужели проще самому бабахаться с UTF-8, нежели воспользоваться ICU?

vsb>Не пользовался им. Это же что-то большое на мегабайты? Мне от строк нужна итерация по кодепоинтам. Всякие заумности обычно не нужны. UTF-8 достаточно простой формат и реализуется в несколько десятков строк кода. Если там какие-нибудь сортировки по национальным символам будут нужны, видимо да, ICU нужен будет. А там свой класс строк есть?

Да, ICU -- это большая штука. Поменьше есть https://github.com/nemtrif/utfcpp

Свой класс строк там есть, UnicodeString, но, скорее всего, там унутрях не UTF-8 представление.

ЕМПИП, итерироваться по кодепоинтам можно и храня содержимое в std::string, просто сделав несколько свободных функций (вспомогательных классов).

Здравствуйте, vsb, Вы писали:

vsb>Здравствуйте, AlexGin, Вы писали:

AG>>Это субъективно (точнее — из-за отсутствия опыта работы с STL).

vsb>Это от наличия опыта. И наличия опыта работы с библиотеками в других языках. Кстати STL далеко не самое ужасное, что есть в C++.
Мы (вроле как) о C++ и об STL, а не о других языках. Да, в .NET и в Java сделано иначе. Но это не означает, что в STL хуже.

vsb>Больше всего меня ужасает ввод-вывод. Это же надо догадаться было — перегрузить операторы битового сдвига. Какая-то шизофрения.
Всё логично — мы можем двигать биты, и можем двигать информацию на вывод. Всё логично и просто.

AG>>Откройте для себя книгу Н. Джосаттиса "Стандартная библиотека C++"

vsb>Если мне не изменяет память, я эту книгу читал году в 2005.

Это старая редакция, теперь уже есть по C++11 (и выше).

Р>Но! Есть адекватная замена крестам https://codeberg.org/kiesel-js/kiesel

Здравствуйте, so5team, Вы писали:


S>По тем временам, когда в наличии был только Си-шный printf и в языке даже на шаблоны еще намека не было, это был прям таки прорыв.

Для выводы обычных строк, символов, чисел printf удобней

Здравствуйте, CRT, Вы писали:

S>>По тем временам, когда в наличии был только Си-шный printf и в языке даже на шаблоны еще намека не было, это был прям таки прорыв.

CRT>Для выводы обычных строк, символов, чисел printf удобней

Расскажите эту байку кому-нибудь помоложе.

Здравствуйте, so5team, Вы писали:

S>...
S>Скорее всего, там была не запарка, а сознательное решение обеспечить сохранность итераторов при модификации, чтобы std::unordered_map мог быть прямой заменой std::map. В результате убили главное преимущество хэш-таблиц и получили рекомендацию не использовать std::unordered_map там, где требуется производительность.

А где про это можно почитать? Очень интересно. У нас наоборот тащат везде unordered_map, типа он быстрее (понятно что в идеальных случаях на больших контейнерах — да).

Здравствуйте, SaZ, Вы писали:

SaZ>А где про это можно почитать? Очень интересно. У нас наоборот тащат везде unordered_map, типа он быстрее (понятно что в идеальных случаях на больших контейнерах — да).

Боюсь это все раскидано в разных блог-постах, вопросах на Stackoverflow, докладах на разных конференциях и т.д.
Типа вот такого: https://www.reddit.com/r/programming/comments/5pwgtn/hash_map_benchmark_stdunordered_map_seems_very/

Большая статья с бенчмарками: https://tessil.github.io/2016/08/29/benchmark-hopscotch-map.html

Здравствуйте, so5team, Вы писали:

CRT>>Для выводы обычных строк, символов, чисел printf удобней

S>Расскажите эту байку кому-нибудь помоложе.
Конечно, ведь

std::cout << "0x" << std::hex << std::setfill('0') << std::setw(4) << 0x424 << std::endl;

гораздо удобней чем

printf("0x%04x\n", 0x424);

Здравствуйте, Shmj, Вы писали:

S>Возможная причина, кмк, непростая парадигма времени компиляции. Шаблоны те же бывают трех-четырех и пяти этажные... В может и не в этом дело.

(Verse 1)
Yo, listen up, here's a tale to tell,
'Bout this beast of a language, that we know so well.
C++, we've been through hell,
Complex syntax — ain't it a hard sell?

Chasing bugs through the night, pointer's out of sight,
Memory leaks, undefined behavior, giving us a fright.
Templates and exceptions, got our heads in a spin,
You've got to be an expert to even begin.

(Chorus)
'Cause C++'s like a riddle in the dark,
A million ways to compile, but where do you start?
Complexity stacked high, like a work of art,
Coding in C++, tearing minds apart.

(Verse 2)
Overload resolution, what a convolution,
Endless compile times — ain't no resolution.
Type safety's compromised, casting wide and far,
You can shoot yourself in the foot, don't know where you are.

Got legacy code, outdated and old,
Backwards compatibility, a stranglehold.
With header files and macros, what a bitter pill,
C++ got us chasing that overkill.

(Chorus)
'Cause C++'s like a journey through the abyss,
An intricate dance, hit or miss.
Ain't no guiding star, no state of bliss,
Coding in C++, it's a game of risk.

(Outro)
Yeah, we keep grindin', through the noise and clutter,
But the pains of C++, make us stutter.
It's a powerful tool, no other can smother,
But, oh C++, you're a difficult mother.


//машины ответ