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

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

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

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

Здравствуйте, 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 лет как исчезла точно необходимость самому всё реализовывать. Даже и раньше отчасти.

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

П>>Что Qt?

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

Да. Если гуй на Qt пишешь, можно кутишные типы использовать. Всё равно это не свои велосипеды, а де факто стандарт для гуёвых приложений


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

Я так делал много раз, никаких проблем.

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

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

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

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

Здравствуйте, 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.

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

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

[]

N>Моя базовая библиотека OpenCV
N>Даже этот же код, переписанный на Питон выглядит хуже.

Там одна путаница row-column vs. column-row чего стоит. Запихнули бы это давно када-нибудь на уровень биндингов и ручку для настройки поведения, для обратной совместимости.

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

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

А в чем проблема? Ну, будет на границах переконвертация в/из, и что?

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

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

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

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

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

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

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