Продуктивность разработки на C++.

Да. Нет.

Так а когда будет обнаружен второй False? Или прострелом ноги называется потенциальный крах приложения?

Да. Нет.

Где отмена? Вон с форума.

А вот и отличная иллюстрация почему в C++ легко выстрелить в ногу. UB сам найдёшь?

Упс.

bool starts_with(const std::string& string, const std::string& pattern)
{
  return pattern.size() <= string.size() && std::equal(pattern.begin(), pattern.end(), string.begin());
}

Почему Петросянство?

Потому что во-первых, ты написал не имеющий отношения к реальности кусок псевдокода, во-вторых, ничего подобного в стандартной библиотеке нет, а речь идёт именно про неё.

Не уж то нет библиотек, которые умеют парсить JSON одной строчкой кода? Мне просто лень искать, но что нереального я написал?

Смотри: тебе даже день посмотреть какие есть библиотеки для парсинга json, а разработчикам нужно посмотреть, сравнить, разобраться с API, поставить, подключить к сборке и протестировать на всех целевых платформах. И ты наверное ещё и не знаешь какая боль - использование внешних зависимостей под вендой. Это ещё одна замечательная иллюстрация непродуктивности C++.

Т.е. в Python можно сделать проще?

parts = s.split()

Что-то не находится.

Вот и я о том же: ты не просто выстрелил себе в ногу, но и не можешь понять как несмотря на то что тебе на это явно указали. Хинт: что будет если pattern длиннее строки?

Почему-то подумалось, что equal сверяет InputIterator2 с end().

Каким ещё end()? Ты даже не знаешь языка который пытаешься защищать?

Но, честно говоря, если бы я писал реальный код, то я бы сверился с документацией. Так что не могу согласиться, что это реальная проблема C++.

Ты сейчас признал что на C++ нельзя писать без сверки с документацией, и при этом не считаешь это проблемой. Ok.

Либо только после изучения всей цепочки «железо-коды-асм-си-...»

C++ — это кроссплатформенный язык.

Какое железо и какой асм предлагается изучать? Как это поможет понять кроссплатформенный, железонезависимый язык?

Потому что во-первых, ты написал не имеющий отношения к реальности кусок псевдокода, во-вторых, ничего подобного в стандартной библиотеке нет, а речь идёт именно про неё.

Ну в стандартной библиотеке нет парсера JSON. Это факт.

Смотри: тебе даже день посмотреть какие есть библиотеки для парсинга json, а разработчикам нужно посмотреть, сравнить, разобраться с API, поставить, подключить к сборке и протестировать на всех целевых платформах

Да пожалуйста. Вот я прям сейчас нашёл header-only библиотеку для JSON на C++ - https://github.com/nlohmann/json#examples:

// create object from string literal
json j = "{ \"happy\": true, \"pi\": 3.141 }"_json;

Вот и я о том же: ты не просто выстрелил себе в ногу, но и не можешь понять как несмотря на то что тебе на это явно указали. Хинт: что будет если pattern длиннее строки?

Уже увидел. Спасибо.

Или прострелом ноги называется потенциальный крах приложения?

Ну да, тебе ж на UB указали

Ты сейчас признал что на C++ нельзя писать без сверки с документацией

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

Каким ещё end()? Ты даже не знаешь языка который пытаешься защищать?

С string.end(). Что значит не знаю? На определённом уровне я его знаю. Но это у всех так. И я его защищаю.

Ты сейчас признал что на C++ нельзя писать без сверки с документацией, и при этом не считаешь это проблемой.

А на Python разве можно писать без сверки с документацией?

С pattern.end(). Что значит не знаю? На определённом уровне я его знаю. Но это у всех так.

Итератор по string с pattern.end()? Ну-ну.

Итератор по string с pattern.end()? Ну-ну.

Да нет же. first2 + (i - first1) c string.end().

string.end(), который ты не передал в вызов? Ну-ну.

На определённом уровне я его знаю. Но это у всех так.

Нет, и как раз, таким как ты, лучше брать какой-нибудь QtCore и использовать его вместо стандартной библиотеки. Будет почти как python.

string.end(), который ты не передал в вызов? Ну-ну.

А, ну да. Ну, бывает, короче. Но это бывает в любом языке и у всех. Или имеются объективные аргументы, что где-то такое не бывает?

Нет, и как раз, таким как ты, лучше брать какой-нибудь QtCore и использовать его вместо стандартной библиотеки. Будет почти как python.

Обоснуешь? А то я за подобными обоснованиями сюда и пришёл.

Ты сначала определи, что именно «бывает»

Ты сначала определи, что именно «бывает»

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

Попробуй писать реальные программы на одном и другом. Хоть мелкие утилиты. А не офигительные вопросы задавай, чтобы пересказывались шаблоны про светлое будущее коммунизма.

Но это бывает в любом языке и у всех

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

Попробуй писать реальные программы на одном и другом. Хоть мелкие утилиты. А не офигительные вопросы задавай, чтобы пересказывались шаблоны про светлое будущее коммунизма.

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

Вопрос лишь в том, к чему это может привести в случае питона и C++

В случае Питона это может привести к чему угодно, так же, как и в случае с C++. И то, что Питон не свалится в корку, ещё не говорит о том, что последствия от False-результата не приведут к чему-то ужасному. Это смотря чем управляет программа на Питоне. Так что опять же не всё так однозначно.

Или имеются объективные аргументы, что где-то такое не бывает?

Бывает, просто в одних языках это исключения, а в других правило, этом и определяется продуктивность.

А все объективные аргументы ты привёл сам - полез со второго раза искать и подключать внешнюю библиотеку (вместо import json), написал 5 строк неочевидного и крайне неэффективного кода на потоках (вместо .split()) и написал (опять таки) свою велосипедную функцию, в единственной строке которой допустил фатальную ошибку (вместо .startswith()). И это только три простейших примера.

В случае Питона это может привести к чему угодно, так же, как и в случае с C++

Не-а. Это не приведёт к тому, что ты запишешь в чужую память, например.

Да, программа на питоне, в отличие от оной на C++, свалится с трейсом во множестве случаев, где подобная на C++ просто не скомпилируется. Но отлаживать программу на питоне будет проще на порядок.

В случае Питона это может привести к чему угодно, так же, как и в случае с C++

Ложь. В питоне гораздо меньше случаев неопределённого поведения, поведение программы предсказуемо и в корку ничего не валится. startswith с большей строкой в качестве аргумента всегда False - определено и очевидно. Обращение к несуществующему элементу массива - исключение - определено и очевидно. И т.д.

крайне неэффективного кода на потоках (вместо .split())

Питоновский split, если что, тоже крайне неэффективное решение. Первый же нагугленный бенчмарк показывает, что он даже медленнее потоков:

https://github.com/tobbez/string-splitting

Не говоря уж о том, что если в С++ также взять иммутабельный string_view, то питон будет в полном пролете.

Бывает, просто в одних языках это исключения, а в других правило, этом и определяется продуктивность.

Ну, наверное, это так.

полез со второго раза искать и подключать внешнюю библиотеку (вместо import json)

Согласен, это контрпродруктивно, но я быстро нашёл библиотеку для JSON. Другое дело, насколько она качественна, будучи нестандартной.

написал 5 строк неочевидного и крайне неэффективного кода на потоках (вместо .split())

Неэффективного по сравнению с чем? Если ты про split() Питона, то я думаю, что мой код на потоках будет в сто крат эффективнее.

в единственной строке которой допустил фатальную ошибку (вместо .startswith())

Ну, это бывает везде.

Как бы там ни было, неужели на C++ продуктивными могут быть только киборги и/или гении, которые никогда не допускают ошибок?

поведение программы предсказуемо

Ложь. Кривой код на питоне может в корку и не валиться, но логика его работы бывает практически непостижимой.

Мы здесь не сравниваем производительность питона и C++.

Не-а. Это не приведёт к тому, что ты запишешь в чужую память, например.

Я о другом говорю. Допустим программа на Питоне управляет каким-нибудь жизненноважным аппаратом. И тут во время выполнения возвращается False, вместо True. Всё. жизненоважный аппарат работает не так, как надо. Ну и что толку от того, что сам Питон от этого не упадёт? Я об этом говорю, а не о UB в понимании записи в память.

«Постижимость» это всего лишь мера компетентности того кто код читает, и она тут не при чём. Я повторяю - код будет предсказуем, это значит что на одних и тех же данных он будет вести себя одинаково, и его можно будет разобраться по шагам, показав почему результат получился именно таким. А C++, где возможны неинициализированные данные и запись в память освобождённых объектов, где уже могут лежать совершенно другие объекты - такими свойствами не обладает.

неужели на C++ продуктивными могут быть только киборги и/или гении, которые никогда не допускают ошибок?

Нет, если ты не входишь в эти две категории, то тебе необходимо вручить тот же QtCore, например, запретить использовать голые указатели, влупить, например, clang-tidy в связке з git, и продуктивность будет вполне на уровне. У нас работают в том числе студенты, вполне себе справляются.

Ложь.

Смотри мой комментарий https://www.linux.org.ru/forum/development/13758732?cid=13760059 (комментарий).

тебе необходимо вручить тот же QtCore, например, запретить использовать голые указатели, влупить, например, clang-tidy в связке з git, и продуктивность будет вполне на уровне.

То есть твой рецепт продуктивности на C++ - QtCore + clang-tidy + git?

Про эффективность речь не идёт. На rust, d, go будет в разы меньше кода с почти той же производительностью. И без граблей.

Это уже словоблудие не имеющее отношение к обсуждению.

Как бы там ни было, неужели на C++ продуктивными могут быть только киборги и/или гении, которые никогда не допускают ошибок?

Я уже писал что нужно чтобы писать на плюсах продуктивно. Но на самом деле это бессмысленный вопрос. Правильный вопрос - в каких случаях низкая продуктивность плюсов оправдывается большей эффективностью кода. И ещё хороший вопрос на что их заменить с увеличением продуктивности и без потери производительности.

на одних и тех же данных он будет вести себя одинаково, и его можно будет разобраться по шагам

Святая наивность. В сложных программах есть масса случаев, когда на руках ты имеешь только результат, не зная ни изначальных данных, ни имея возможности их повторить. Особенно, если эта проблема проявляется у пользователя в зависимости от фаз луны.

А C++, где возможны неинициализированные данные и запись в память освобождённых объектов, где уже могут лежать совершенно другие объекты - такими свойствами не обладает.

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

На rust, d, go будет в разы меньше кода с почти той же производительностью. И без граблей.

Пилите Пишите, Шура, пишите.

Святая наивность. В сложных программах есть масса случаев, когда на руках ты имеешь только результат, не зная ни изначальных данных, ни имея возможности их повторить. Особенно, если эта проблема проявляется у пользователя в зависимости от фаз луны.

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

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

Святая наивность. Компиляторы позволяют, а списки CVE только растут и растут, и фаззинг рулит.

Вы хоть читаете на что отвечаете?

Да, на то, что якобы поведение программы на питоне предсказуемо. По такой логике поведение и программ на С и С++ предсказуемо.

Святая наивность. Компиляторы позволяют, а списки CVE только растут и растут, и фаззинг рулит.

Это как ездить на велосипеде и учить гонщиков F1 (авторов того же linux kernel) водить и указывать на их ошибки. Очевидно, что есть задачи, где писать опасный код просто необходимо. В том же коде на Rust полно unsafe, многие из них просто попрятали в стандартную библиотеку. Но все там за тебя не сделают, и если ты полезешь решать системные задачи, или даже многие простые, - ты везде накосячишь и с любым языком.

Да и в этой массе, не хочешь ли ты заявить что отладка кода который записал мусор по левому адресу будет проще отладки когда который упал по исключению с трейсом?

А кто тебе сказал, что он упал? Кривой код может просто похерить данные и продолжит работать. Простой пример, когда-то драйвер от nvidia радостно удалял /usr, используя «безопасный» sh.

Тему удалить. Она завтра протухнет

Да, на то, что якобы поведение программы на питоне предсказуемо. По такой логике поведение и программ на С и С++ предсказуемо.

Предсказуемость означает что программа делает то что написано в коде. Да, на питоне предсказуемо, на C/C++ нет.

Очевидно, что есть задачи, где писать опасный код просто необходимо.

Наверное ты хотел сказать «потенциально небезопасный». Очевидно, есть. Также очевидно, что тысячи уязвимостей находят в самом разном софте, где очевидно, не только нет никакой необходимости в небезопасном коде, но и явно нужна безопасность. Браузеры и openssl, например.

Но речь-то вообще была не об этом, а о твоём заявлении:

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

Очевидно лживом, потому что убирание большинства проблем должно, очевидно, подразумевать уменьшение количества уязвимостей по меньшей мере в 2 раза, чего не наблюдается даже близко.

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

Не надо путать ограниченных набор явно обозначенных, а по тому многократно перепроверенных unsafe кусочков в Rust, и абсолютно весь код unsafe в плюсах.

Я повторюсь: вы не читаете на что отвечаете, и пишете текст никак не связанный с обсуждением. Если у вас так туго с этим, формулирую максимально просто: определённые классы ошибок, возможные в C++, невозможны в питоне, обратное утверждение неверно.

В жизненноважном аппарате очень важно и то, насколько быстро ты исправишь проблему.

Предсказуемость означает что программа делает то что написано в коде. Да, на питоне предсказуемо, на C/C++ нет.

Кривая программа на С/С++ делает ровно тоже самое, что написано в коде. Сказали записать в левый адрес - будет сделано. И будет по этому адресу ровно то, что туда положили ранее. И точно так же в питоне похеренные данные могут проявиться не сразу, а через большой промежуток времени. И что в С++ с gdb + valgrind (если ранее не использовал санитайзеры), что в питоне с дебаггером, ты будешь пытаться поймать этот момент при отладке.

Очевидно лживом, потому что убирание большинства проблем должно, очевидно, подразумевать уменьшение количества уязвимостей по меньшей мере в 2 раза, чего не наблюдается даже близко.

Очевидно ты просто не понял, что я написал.

https://clang.llvm.org/docs/AddressSanitizer.html https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html

и пр. Вполне себе вариант, если не требуется максимальная производительность.

Не надо путать ограниченных набор явно обозначенных, а по тому многократно перепроверенных unsafe кусочков в Rust, и абсолютно весь код unsafe в плюсах.

Я абсолютно согласен, что Rust помогает избегать многих ошибок, и это его большой плюс, но не панацея. Особенно, если использовать его там, где нельзя было бы обойтись более попсовым и еще более безопасным языком.

Я повторюсь: вы не читаете на что отвечаете, и пишете текст никак не связанный с обсуждением. Если у вас так туго с этим, формулирую максимально просто: определённые классы ошибок, возможные в C++, невозможны в питоне, обратное утверждение неверно.

Нет, это ты пытаешься соскочить с изначального тезиса про «поведение программы предсказуемо», уходя в частности и переходя на личности. И эти «определенные классы ошибок» на самом деле ничто иное как частный случай порчи данных, что делается разными способами, но на всех языках не составляет проблемы.

И что в С++ с gdb + valgrind (если ранее не использовал санитайзеры), что в питоне с дебаггером, ты будешь пытаться поймать этот момент при отладке.

Как интересно. Несколькими сообщениями выше ты писал про «на руках ты имеешь только результат, не зная ни изначальных данных, ни имея возможности их повторить», а теперь уже gdb и valgrind доступны?

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

Очевидно ты просто не понял, что я написал.

Я знаю что такое санитайзеры. Я говорю что они ловят не всё и используются не всеми, поэтому в глобальной перспективе язык от них более безопасным не становится. Софт на C++ как был решетом так и остался, иди попробуй продай свои санитайзеры всем кто на нём пишет.

Нет, это ты сводишь разные классы ошибок к сферической «порче данных» в вакууме, и делаешь вывод что она возможна во всех языках. Логично чо. Только если глаза разуть, то там где в C++ ты не попав в массив тихо изменил то что расположено за ним, и нашёл это только под valgrind, которого у тебя, как ты сам же сказал и так удобно забыл, может и не быть, в питоне ты получил исключение. As easy as that.