Re[5]: Десктопные на голом C не выглядят монструозными - Компьютерные священные войны

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

S>Одну маленькую таки пришлось написать, но для ее написания пришлось перелопатить примерно 50 экранов кода.

Примем экран==100 строк. 50 экранов — 5000 строк. Это была студенческая лаба?

S>Думаю что да, кое-какие ритуалы будут раздражать. Однако же скорость написания будет не многим ниже — видимо те самые 20% о которых говорят, которые добавляют удобные инструменты.

У меня сейчас небольшой проект, только начал подбираться к 100KLOC. Пишу месяца три. Стороннего там ничего нет, только своё, на плюсах и его стандартной библиотеке. А, ну ещё там некоторое количество своих библиотек, кочующих из проекта в проект и развивающихся по мере необходимости, которые тоже на плюсах и стандартной библиотеке. Хотя вру — одна стороння либа есть — для разбора JSON. Тоже чисто плюсовая.

Пишу один.

Так вот, на сишечке я бы не стал даже пытаться его сделать — в разумные сроки его просто было бы не сделать. 1) куча бойлерплейта, который не только замедляет написание, но и усложняет восприятие — одно и тоже на плюсах в итоге гораздо быстрее написать рабочее, чем на сишечке; 2) баги, из-за которых либо приложение было бы таким же глючным, как GTKшный софт, либо сроки растянулись бы на годы.

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

Некоторый опыт на сишечке имеется. Я как-то писал на сишечке HTTP-сервер для микроконтроллера, что заняло у меня пару месяцев. Тот проект был очень простым по сравнению с текущим.

Так что ты не думай, гражданин теоретик, а попробуй написать что-то сложнее лабораторки

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

S>Одну маленькую таки пришлось написать, но для ее написания пришлось перелопатить примерно 50 экранов кода.
Ну и как? Взбодрился после такого?

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

S>Думаю что да, кое-какие ритуалы будут раздражать.
Более чем, ты даже не представляешь как они будут раздражать, но это ты не залезаешь ещё дальше в glib. Весь gobject это тонны болерплейта и только 5-6 строк кода которые тебе нужны.
S>Однако же скорость написания будет не многим ниже — видимо те самые 20% о которых говорят, которые добавляют удобные инструменты.
Я думаю с QT было бы быстрее и вероятнее всего на 40% ниже.

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

S>Для примера давайте покритикуем https://gitlab.gnome.org/GNOME/nautilus

https://gitlab.gnome.org/GNOME/nautilus/-/blob/master/src/nautilus-bookmark.c#L82

static void
nautilus_bookmark_set_name_internal (NautilusBookmark *bookmark,
                                     const char       *new_name)
{
    if (g_strcmp0 (bookmark->name, new_name) != 0)
    {
        g_free (bookmark->name);
        bookmark->name = g_strdup (new_name);

        g_object_notify_by_pspec (G_OBJECT (bookmark), properties[PROP_NAME]);
    }
}

`bookmark->name` сначала удаляется, а потом копируется новый, но что если `g_strdup (new_name)` не сможет выделить память? `bookmark->name` будет присвоено NULL, и потом при обращении к нему программа упадёт. Мало того, что обработки ошибок никакой нет, эта операция в таком виде принципиально небезопасна. Сначала надо выделять новый ресурс, а потом уже при успешном выделении освобождать старый. В C++ это хорошо известно из-за исключений, и называется strong exception safety guarantee.

Этот пример я нашел навскидку. Думаю там весь код написан в таком стиле.

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

S>По идее высокоуровневые приложения на голом С должны быть ад и армагедон.
Они и есть ад и армагеддон.

S> Но нет — они не выглядят так уж слишком страшными, примерно как на Python — без особой разницы.
S>Вот тут много: https://gitlab.gnome.org/GNOME — в ООП-стиле на голом Си.
Это совсем не голый С.
У них активно используется аналог деструкторов через GCC extension: https://blogs.gnome.org/desrt/2015/01/30/g_autoptr/
Что уже крайне сильно меняет расклад.
Вообще в последнее время С потиху превращается в ранний С++.

... << RSDN@Home 1.3.110 alpha 5 rev. 62>>

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

S>> Но нет — они не выглядят так уж слишком страшными, примерно как на Python — без особой разницы.
S>>Вот тут много: https://gitlab.gnome.org/GNOME — в ООП-стиле на голом Си.
CC>Это совсем не голый С.
CC>У них активно используется аналог деструкторов через GCC extension: https://blogs.gnome.org/desrt/2015/01/30/g_autoptr/
CC>Что уже крайне сильно меняет расклад.
CC>Вообще в последнее время С потиху превращается в ранний С++.

Так и что, разве это требует изменения самого языка или компилятора? Использование доп. библиотек с нужным функционалом — никто не запрещает.

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

S>По идее высокоуровневые приложения на голом С должны быть ад и армагедон.

Задрачиваться на конкретный язык — признак студента первого курса. Язык нужно выбирать тот, который позволяет оптимально (!!!) решить конкретную задачу. Оптимально — как с точки зрения самой задачи так и с со стороны квалификации исполнителя. Все крики что делфи/с/яваскрип/питон/и т.п — говно, а нужно использовать только ххх, как самый кошерный — это маркер профнепригодности.

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

Ф>Как тебе это удалось?
Смарт поинтеры, контейнеры, array вместо chat*, ну ты понял. Чтобы использовать голые указатели в С++ надо серьёзно обосновать свой выбор.

tokei-i686-pc-windows-msvc.exe my_small_project
===============================================================================
 Language            Files        Lines         Code     Comments       Blanks
===============================================================================
 C Header              489        31351        26965          439         3947
 C++                   351       141269       132324         1501         7444
===============================================================================
 Total                 840       172620       159289         1940        11391
===============================================================================

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

CC>>У них активно используется аналог деструкторов через GCC extension: https://blogs.gnome.org/desrt/2015/01/30/g_autoptr/

Pzz>Местами может и используется, но совсем не "активно".

Немного произвольно потыкал — везде g_autoptr. Ну, если это "не активно"...

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

S>По идее высокоуровневые приложения на голом С должны быть ад и армагедон. Но нет — они не выглядят так уж слишком страшными, примерно как на Python — без особой разницы.

А на чем они не ад и армагедон? Существующие тулкиты, все двое, Qt и GTK, подразумевают ад и армагедон, к какому языку их не приладь.

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

Pzz>Ну в общем и целом, во всех моих крупных сишных проектах сначала закладывается инфраструктура, которая упрощает общие вещи —

логи — много где — не нужны. Вот сейчас — мне не нужны
автоматизация управления памятью — в C++ — искаропки
строки/вектора — в C++ — искаропки
дофига всего остального, что используется, например, у меня в текущем проекте — set/map/unordered_*, всякие алгоритмы — в C++ — искаропки

Pzz>а потом становится все равно, на чем писать, и код пишется по сути решаемой проблемы, а не для борьбы с языком.

Да вот нифига, на сишечке всё равно приходится бороться с ней

П>>Некоторый опыт на сишечке имеется. Я как-то писал на сишечке HTTP-сервер для микроконтроллера, что заняло у меня пару месяцев. Тот проект был очень простым по сравнению с текущим.

Pzz>Странно как-то. 100 тысяч строк ты пишешь за 3 месяца, а я за полтора года. Но при этом HTTP-сервер ты пишешь за два месяца, а я за неделю напишу (если на Си).

Ничего странного. Написал строки, затем текстовые макроподстановки, потом сам сервер. Потом — сайт на сишечке. Шаблоны страниц — в виде текста с макросами (иначе не влезало и/или было слишком геморно). Дизайн — тоже сам. Иконки кое-какие нарисовал. Проверил всё под хром/ие/файрфокс, поправил, что где не работало. Потом сдал всё это заказчику и получил бабос. Всё — за два месяца. При том, что это был Turbo C, а целевая платформа — 186ой с каким-то мизером памяти, как оперативки, так и ПЗУ. Ты ещё помнишь, что такое near/far указатели?

Ну и про 100KLOC я конечно подзагнул немного

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

Pzz>>Ну да. В C++ все абсолютно то же самое.

N>stl же! Моя базовая библиотека OpenCV была переписана с С на С++, у неё были строки свои, умные указатели свои и т.д. Теперь это std::string, std::shared_ptr, std::vector. Мой клиентский код отчасти поэтому стал компактней. По факту же, он стал во много-много раз компактнее и понятней за счёт переписывания базовых классов матриц/векторов/точек/прямоугольников/etc на плюсы. Код перестал быть приседаниями с памятью, а стал отражать предметную область. И при этом он стал даже быстрее работать! Даже этот же код, переписанный на Питон выглядит хуже.

Угу. Иди попробуй скрестить строки STL со строками какого-нибудь условного Qt или какого-нибудь другого аналогичного тулкита.

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

S>QT то чем не угодил?

Тем, что он — унылое монстрообразное дерьмо.

S>Поставлю вопрос по другому — что вы видели намного лучше?

Ничего не видел, в том и беда.

Здравствуйте, uncommon, Вы писали:
> Сначала надо выделять новый ресурс, а потом уже при успешном выделении освобождать старый.

Вообще так себе идея.
Если старый ресурс не удалить, то новый может и не загрузиться, так как памяти не хватит.
И что тогда толку с гарантий, если приложение не работает.
Лично сталкивался c такой ситуацией.

Вот вы писали, что сахар крайне важен.

По идее высокоуровневые приложения на голом С должны быть ад и армагедон. Но нет — они не выглядят так уж слишком страшными, примерно как на Python — без особой разницы.

Вот тут много: https://gitlab.gnome.org/GNOME — в ООП-стиле на голом Си.

Для примера давайте покритикуем https://gitlab.gnome.org/GNOME/nautilus

Думаете на высокоуровневом — это же будет намного меньше по объему кода а код будет яснее?

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

CC>>У них активно используется аналог деструкторов через GCC extension: https://blogs.gnome.org/desrt/2015/01/30/g_autoptr/
CC>>Что уже крайне сильно меняет расклад.
CC>>Вообще в последнее время С потиху превращается в ранний С++.

S>Так и что, разве это требует изменения самого языка или компилятора? Использование доп. библиотек с нужным функционалом — никто не запрещает.

Я для тебя выделил

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

S>Настоящий программист напишет программу ~~на Фортран~~ на любом языке программирования!

исправил

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

S>>Настоящий программист напишет программу ~~на Фортран~~ на любом языке программирования!

_>исправил

Да вы, батенька, настоящий программист и есть. Про таковых, собственно, и была оригинальная цитата.

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

S>Думаете на высокоуровневом — это же будет намного меньше по объему кода а код будет яснее?
Давай начнём обсуждение с того, сколько ты написал программ с помощью gobject? Вот когда напишешь хоть что-то, тогда поговорим.

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

S>>Думаете на высокоуровневом — это же будет намного меньше по объему кода а код будет яснее?
K>Давай начнём обсуждение с того, сколько ты написал программ с помощью gobject? Вот когда напишешь хоть что-то, тогда поговорим.

Одну маленькую таки пришлось написать, но для ее написания пришлось перелопатить примерно 50 экранов кода.

Думаю что да, кое-какие ритуалы будут раздражать. Однако же скорость написания будет не многим ниже — видимо те самые 20% о которых говорят, которые добавляют удобные инструменты.

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

S>>Одну маленькую таки пришлось написать, но для ее написания пришлось перелопатить примерно 50 экранов кода.
П>Примем экран==100 строк. 50 экранов — 5000 строк. Это была студенческая лаба?

Мне нужна была только часть функционала. В оригинальном проекте строк около 15 тыс — все изучать не нужно было. Да, небольшой.

П>Некоторый опыт на сишечке имеется. Я как-то писал на сишечке HTTP-сервер для микроконтроллера, что заняло у меня пару месяцев. Тот проект был очень простым по сравнению с текущим.

П>Так что ты не думай, гражданин теоретик, а попробуй написать что-то сложнее лабораторки

Была такая мысль. Пришел сюда чтобы меня отговорили.

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

П>...100KLOC..., только своё, на плюсах и его стандартной библиотеке....У меня нет никаких голых указателей;

Как тебе это удалось?

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

П>У меня сейчас небольшой проект, только начал подбираться к 100KLOC. Пишу месяца три.

Это 100KLOC самого проекта или же суммарно с вашими готовыми либами и сторонней JSON-библиотекой?

П>У меня сейчас небольшой проект, только начал подбираться к 100KLOC. Пишу месяца три. Стороннего там ничего нет, только своё, на плюсах и его стандартной библиотеке. А, ну ещё там некоторое количество своих библиотек, кочующих из проекта в проект и развивающихся по мере необходимости, которые тоже на плюсах и стандартной библиотеке. Хотя вру — одна стороння либа есть — для разбора JSON. Тоже чисто плюсовая.

П>Пишу один.

100к ?
малАватА будет
cd my_small_project
"C:\Program Files\Git\usr\bin\find.exe" . -type f -name \*.* | "C:\Program Files\Git\usr\bin\xargs.exe" "C:\Program Files\Git\usr\bin\wc.exe" -l
172379 total
только .cpp и .h

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

П>>...100KLOC..., только своё, на плюсах и его стандартной библиотеке....У меня нет никаких голых указателей;

Ф>Как тебе это удалось?

Стандартная библиотека? Не, не слышал.

Хотя, конечно, указатели немножко есть. Иногда что-то опциональное в/из функций передаётся. И то, потому что я ленивый и плохо знаю новые библиотеки языка и с optional лень заморачиваться

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

П>>У меня сейчас небольшой проект, только начал подбираться к 100KLOC. Пишу месяца три.

S>Это 100KLOC самого проекта или же суммарно с вашими готовыми либами и сторонней JSON-библиотекой?

Без.

Для статы использую github.com/AlDanial/cloc, у ней есть опции что эксклюдить из подсчета

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

П>>>У меня сейчас небольшой проект, только начал подбираться к 100KLOC. Пишу месяца три.

S>>Это 100KLOC самого проекта или же суммарно с вашими готовыми либами и сторонней JSON-библиотекой?

П>Без.

Ну ахринеть!

У меня хорошо, если 3KLOC в месяц выходит (не считая тестов).

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

S>>>Это 100KLOC самого проекта или же суммарно с вашими готовыми либами и сторонней JSON-библиотекой?

П>>Без.

S>Ну ахринеть!

S>У меня хорошо, если 3KLOC в месяц выходит (не считая тестов).

Ну, я урезал осетра

Повнимательнее глянул — одна либа таки пробралась, и в стате там обо всех файлах, не только плюсовых. Чисто плюсового около 45KLOC.

Ну, и я люблю писать воздушно — 30% blank

Итого чисто кода получается 30KLOC.

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

S>Так и что, разве это требует изменения самого языка или компилятора?
Конечно!

S> Использование доп. библиотек с нужным функционалом — никто не запрещает.
Это нельзя сделать библиотечно.

... << RSDN@Home 1.3.110 alpha 5 rev. 62>>

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

П>>У меня нет никаких голых указателей;
Ф>Как тебе это удалось?
С++ же

... << RSDN@Home 1.3.110 alpha 5 rev. 62>>

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

R>cd my_small_project
R>"C:\Program Files\Git\usr\bin\find.exe" . -type f -name \*.* | "C:\Program Files\Git\usr\bin\xargs.exe" "C:\Program Files\Git\usr\bin\wc.exe" -l
R>172379 total
R>только .cpp и .h

Позанудствую

-type f -name \*.* намекает, что вообще все файлы. Может конечно у тебя там ничего другого, кроме cpp и .h и нет, но это тоже надо суметь.

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

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

S>>По идее высокоуровневые приложения на голом С должны быть ад и армагедон.

_>Задрачиваться на конкретный язык — признак студента первого курса. Язык нужно выбирать тот, который позволяет оптимально (!!!) решить конкретную задачу. Оптимально — как с точки зрения самой задачи так и с со стороны квалификации исполнителя. Все крики что делфи/с/яваскрип/питон/и т.п — говно, а нужно использовать только ххх, как самый кошерный — это маркер профнепригодности.

А как же general purpose(оно же универсальные ЯП)? ХабраБлогеры C к универсальным относят.

PS повторюсь. лучший не тот который лучше к задаче, т.к. это инструмент, и если я не умею им пользоваться,
то лучше я сделаю как умею(Парадокс Блаба)
конечно приятно владеть лучшим из инструментов, но на это нужно время и должны быть перспективы применения. путь одиночек.
тот же C# вполне себе середина, пусть и не золотая. можно и шашкой помахать и на еду заработать. последнее время появляется много готовых компонентов, фрэймворков и технологий очень неплохого качества.
как пример https://devblogs.microsoft.com/dotnet/announcing-the-dotnet-community-toolkit-810/
модель до появления фрэймворка могла весить за 100LOC. теперь это 10LOC. Конечно до clojure далеко(рекордсмены по краткости).

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

R>"C:\Program Files\Git\usr\bin\find.exe" . -type f -name \*.* | "C:\Program Files\Git\usr\bin\xargs.exe" "C:\Program Files\Git\usr\bin\wc.exe" -l
R>172379 total

Так оно посчитает и пустые строки и комменты и строки на которых есть просто тупо скобка.
Скачай тот же SourceMonitor — он куда честнее это всё покажет.

... << RSDN@Home 1.3.110 alpha 5 rev. 62>>

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

CC>У них активно используется аналог деструкторов через GCC extension: https://blogs.gnome.org/desrt/2015/01/30/g_autoptr/

Местами может и используется, но совсем не "активно".

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

_>Задрачиваться на конкретный язык — признак студента первого курса. Язык нужно выбирать тот, который позволяет оптимально (!!!) решить конкретную задачу. Оптимально — как с точки зрения самой задачи так и с со стороны квалификации исполнителя. Все крики что делфи/с/яваскрип/питон/и т.п — говно, а нужно использовать только ххх, как самый кошерный — это маркер профнепригодности.

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

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

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

П>Так вот, на сишечке я бы не стал даже пытаться его сделать — в разумные сроки его просто было бы не сделать. 1) куча бойлерплейта, который не только замедляет написание, но и усложняет восприятие — одно и тоже на плюсах в итоге гораздо быстрее написать рабочее, чем на сишечке; 2) баги, из-за которых либо приложение было бы таким же глючным, как GTKшный софт, либо сроки растянулись бы на годы.

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

П>Некоторый опыт на сишечке имеется. Я как-то писал на сишечке HTTP-сервер для микроконтроллера, что заняло у меня пару месяцев. Тот проект был очень простым по сравнению с текущим.

Странно как-то. 100 тысяч строк ты пишешь за 3 месяца, а я за полтора года. Но при этом HTTP-сервер ты пишешь за два месяца, а я за неделю напишу (если на Си).

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

K>Смарт поинтеры, контейнеры, array вместо chat*, ну ты понял. Чтобы использовать голые указатели в С++ надо серьёзно обосновать свой выбор.

chat* — это указатель на чатики?

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

CC>Так оно посчитает и пустые строки и комменты и строки на которых есть просто тупо скобка.
CC>Скачай тот же SourceMonitor — он куда честнее это всё покажет.

А зачем? Они ж линейно связаны. Коэффициент зависит от стиля. Можно просто экспериментально выяснить свой коэффициент, а дальше ограничиваться wc

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

Pzz>>Странно как-то. 100 тысяч строк ты пишешь за 3 месяца, а я за полтора года. Но при этом HTTP-сервер ты пишешь за два месяца, а я за неделю напишу (если на Си).

П>Ничего странного. Написал строки, затем текстовые макроподстановки, потом сам сервер. Потом — сайт на сишечке. Шаблоны страниц — в виде текста с макросами (иначе не влезало и/или было слишком геморно). Дизайн — тоже сам. Иконки кое-какие нарисовал. Проверил всё под хром/ие/файрфокс, поправил, что где не работало. Потом сдал всё это заказчику и получил бабос. Всё — за два месяца. При том, что это был Turbo C, а целевая платформа — 186ой с каким-то мизером памяти, как оперативки, так и ПЗУ. Ты ещё помнишь, что такое near/far указатели?

Я для такого написал полноценный TCP/IP стек. Но вот именно HTTP-сервера у меня не было. HTTP в те времена еще не был изобретен.

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

Pzz>Я для такого написал полноценный TCP/IP стек. Но вот именно HTTP-сервера у меня не было. HTTP в те времена еще не был изобретен.

TCP/IP был в SDK контроллера, под Turbo C, потому на сишечке и пришлось писать. Не помню почему, но TC++/BC++ не заводилось с SDK, или ещё какие-то проблемы были, уже запамятовал. А, да, я ещё тогда мучал сорцы cfront'а неделю, хотелось на плюсиках, хоть на совсем старых, писать, но не срослось

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

Pzz>Ну в общем и целом, во всех моих крупных сишных проектах сначала закладывается инфраструктура, которая упрощает общие вещи — логи, автоматизация управления памятью, строки/вектора, а потом становится все равно, на чем писать, и код пишется по сути решаемой проблемы, а не для борьбы с языком.

А потом приходишь на другой проект — там своя другая инфраструктура, свои строки, вектора. А потом на другой — и там всё свой. И в третьем своё. И в каждом свои особенности и баги.

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

N>А потом приходишь на другой проект — там своя другая инфраструктура, свои строки, вектора. А потом на другой — и там всё свой. И в третьем своё. И в каждом свои особенности и баги.

Ну да. В C++ все абсолютно то же самое.

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

Pzz>Ну да. В C++ все абсолютно то же самое.

stl же! Моя базовая библиотека OpenCV была переписана с С на С++, у неё были строки свои, умные указатели свои и т.д. Теперь это std::string, std::shared_ptr, std::vector. Мой клиентский код отчасти поэтому стал компактней. По факту же, он стал во много-много раз компактнее и понятней за счёт переписывания базовых классов матриц/векторов/точек/прямоугольников/etc на плюсы. Код перестал быть приседаниями с памятью, а стал отражать предметную область. И при этом он стал даже быстрее работать! Даже этот же код, переписанный на Питон выглядит хуже.

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

N>>А потом приходишь на другой проект — там своя другая инфраструктура, свои строки, вектора. А потом на другой — и там всё свой. И в третьем своё. И в каждом свои особенности и баги.

Pzz>Ну да. В C++ все абсолютно то же самое.

Если это не яндекс или что-то подобное, где любят писать свои велосипеды, то нет. Да и то, это во многом из-за того, что многие начинали, когда STL нормально не устоялась. Сейчас — STL/Boost — 90%, + либы из предметной области, + всякие вспомогательные либы. Либы — если не копролит, то они тоже скорее всего на стандартных контейнерах

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

П>Если это не яндекс или что-то подобное, где любят писать свои велосипеды, то нет. Да и то, это во многом из-за того, что многие начинали, когда STL нормально не устоялась. Сейчас — STL/Boost — 90%, + либы из предметной области, + всякие вспомогательные либы. Либы — если не копролит, то они тоже скорее всего на стандартных контейнерах

Qt же.

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

Pzz>Qt же.

Что Qt?

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

Pzz>>Qt же.

П>Что Qt?

У Qt все свое. Строки, вектора...

Если гуёвая часть программы написана на Qt, а не-гуёвая на STL, замучаешься состыковывать...

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

Pzz>Угу. Иди попробуй скрестить строки STL со строками какого-нибудь условного Qt или какого-нибудь другого аналогичного тулкита.

Там уже давно есть норм интероп, проблем нет — проверено. Но и этот твой пример является подтверждением правила, что в древних фреймворках такое ещё было, а сейчас прошло. С C++11 строки стали намного быстрее, всякие emplace методы классные. Уже 12 лет как исчезла точно необходимость самому всё реализовывать. Даже и раньше отчасти.

От:	so5team	https://stiffstream.com
Дата:	02.02.23 09:51
Оценка:	1 (1) +5

	От:	пффф
	Дата:	02.02.23 15:16
	Оценка:	+3

От:	Kernan	https://rsdn.ru/forum/flame.politics/
Дата:	02.02.23 22:03
Оценка:	1 (1) +1

	От:	uncommon
	Дата:	04.02.23 23:33
	Оценка:	2 (1)

	От:	CreatorCray
	Дата:	02.02.23 09:19
	Оценка:	+1

От:	reversecode	google
Дата:	03.02.23 01:28
Оценка:

От:	Pzz	https://github.com/alexpevzner
Дата:	03.02.23 11:38
Оценка:	-1

От:	Философ	http://vk.com/id10256428
Дата:	02.02.23 16:26
Оценка:

От:	Nuzhny	https://github.com/Nuzhny007
Дата:	03.02.23 14:22
Оценка:

	От:	se_sss
	Дата:	09.02.23 10:20
	Оценка:	-1