Почему в этом треде собрались люди, которые про C++ слышали только на ЛОРе, но мнение они уже имеют?

Классика жанра. 95% людей собираются чтобы потрындеть. Знание чего-либо тут не нужно. Главное не задевать их раздутое эго, иначе оно взорвется и содержимое полетит на вентилятор. Просто не нужно слова таких людей воспринимать всерьез. Собака лает - караван идет.

какой-нибудь костыль типа tcp уже больше 30 лет мучают. и ничего, никто не бежит все интернеты переписывать.

Проблема в том, что для эквивалентных языков никто пока не написал 100500 либ, уже написанных для С++.

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

к гобжект стэку

А это что?

какой-нибудь костыль типа tcp уже больше 30 лет мучают. и ничего, никто не бежит все интернеты переписывать.

Взять и все переписать - это подход школоты, которая не занималась проектами дольше нескольких месяцев. Спольски про это хорошо написал (гуглить по «Спольски переписать код с нуля»). Крупные проекты меняют эволюционно.

А что касается tcp, то Гуглы уже стандартизируют свой QUIC, созданный для решения конкретной задачи. И он уже используется параллельно с tcp.

GLib

https://en.wikipedia.org/wiki/GObject

Gtk+, gstreamer. К гстримеру у раста уже намного лучше биндинги, к слову (да и у питона, наверное, тоже), у крестовых до сих пор нет полноценного способа повесить коллбэк к «необернутому» в биндинг сигналу объекта, например, что заставляет писать страшные извращения на си, дергая сишный апи, который, естественно, не дружит с лямбдами и делает жизнь адом.

Что-то не верится, что это прям таки фундаментальная проблема языка. Скорее просто Gtk-шняя дрянь мало кому в C++ вперлась.

Ну и от писателей оберток многое зависит. Доводилось видеть обертки вокруг системных вызовов или ODBC, которые было проще выбросить, чем использовать.

Что-то не верится, что это прям таки фундаментальная проблема языка.

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

Скорее просто Gtk-шняя дрянь мало кому в C++ вперлась.

Ну да, гстример никому не вперся. Да не, все проще: си совместимость — вечная стигма крестов — демотивирует писать нормальные обертки.

какой-нибудь костыль типа tcp уже больше 30 лет мучают. и ничего, никто не бежит все интернеты переписывать.

sctp вон запилили, правда никто не пользуется

Ну если си-поделя не считать крестовыми библиотеками, конечно, но это явно не плюс.

Да хорошая совместимость с C всегда была краеугольным камнем C++. За что, с одной стороны, до сих пор приходится расплачиваться. Но, с другой, какого хрена от готовых С-шных либо отказываться, если их запросто можно использовать?

Ну да, гстример никому не вперся.

Не нужно передергивать. Речь шла про Gtk+. Делать в C++ поддержку маргинальной объектной системы, придуманной исключительно для C, это так себе идея.

какой-нибудь костыль типа tcp уже больше 30 лет мучают. и ничего, никто не бежит все интернеты переписывать.

Я про другое. Вместо того, чтобы при такой серьёзной вехе, как портирование своего ПО на Linux и OS X, взять и улучшить этот самый протокол, они решили «взять и улучшить» кусок стандартной C++либы, более 10 лет тягая с собой этот самопал.

В итоге-то при описанной в посте миграции всё равно выкинули его и перешли на стандартную либу. Вопрос тут у меня был в другом. В том, почему в 2006 году об этом 1С-разработчики не думали? Разве было не очевидно, что их кастомный кусок C++-либы, которую они форкнули, загнётся? Что поддерживать его не хватит сил? Или они ждали чудесного пришествия char16_t из C++11?

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

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

Речь шла про Gtk+.

Речь шла про gobject, на основе которого построен в том числе gstreamer. Нинужно — плохая позиция, особенно, когда изначальный тезис был про 100500 библиотек на каждый чих.

У крестов даже с биндингами к гобжект стэку все очень грустно.

А что не так с gtkmm? Вроде Inkscape его юзает вполне успешно. И тот же кровавый ынтерпрайз в лице VMWare Workstation.

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

А пример этого ада можно увидеть?

А что не так с gtkmm?

Но я не пишу на gtkmm, я использовал gstreamermm. Что не так: биндинг пилится руками и не использует GIO. Твой объект обновился, добавились сигналы? Дописывай биндинг (в итоге биндинг гстримера тупо не поспевает за гстримером, который в каждой ветке обновляется знатно).

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

Нинужно — плохая позиция, особенно, когда изначальный тезис был про 100500 библиотек на каждый чих.

Простите, но тезис был не мой. Это во-первых.

Во-вторых, вы говорите про отсутствие удобных вам биндингов к Gtk+ так, как будто это проблема C++ и его библиотек. Что, вообще-то говоря, совсем не так.

Это в Rust-е нельзя C напрямую использовать. Вот и делают биндинг. В C++ можно использовать тот же Gtk+ в чистом виде. Если вас чистый Gtk+ не устраивает, то вы можете сделать тот биндинг, который вас устроит. Если не можете, то покажите, что в C++ этому препятствует.

Это в Rust-е нельзя C напрямую использовать.

И это прекрасно. В расте я защищен от языка без параметрического полиморфизма, гц/raii, сильной типизации и прочего ужаса, а язык вынуждает писать правильную типобезопасную и каноничную обертку. В итоге в cargo (pip, opam, hackage...) биндинги и библиотеки каноничные, в то время как на крестах все просто дергают сишные биндинги, занимаясь самообманом про шаблоны, raii, constexpr и проч., имея полный nolibs.

А пример этого ада можно увидеть?

Да полно в исходниках же, игра «найди утечку»

https://github.com/GStreamer/gst-plugins-base/blob/master/gst-libs/gst/gl/gbm...

именно поэтому я привёл в качестве примера tcp. протокол.

кто писал на крестах в 90-х знает, что каждая собака писала свои строки. в основном чтобы прикрутить туда sso.

Ну да, гстример никому не вперся.

Судя по тому, что GStreamer выкинули из всех браузеров — Firefox перешёл на FFmpeg, Chrom{e,ium} перешёл на FFmpeg. Судя по его наркоманскому CLI с инопланетными аргументами, судя по той каше из плагинов, аля gst-plugins-base ! gst-plugins-good ! gst-plugins-ugly ! gst-plugins-bad, судя по его тупо сломанному API/ABI в 0.x => 1.x и той дрочи во всех Linux-дистрибутивах, которая последовала за этим изменением...

Ты знаешь, я бы хотел чтобы GStreamer действительно никому не впёрся. Надеюсь, хотя бы Qt-разработчики мигрируют с него на тот же FFmpeg.

Ну да, гстример никому не вперся. Да не, все проще: си совместимость — вечная стигма крестов — демотивирует писать нормальные обертки.

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

Твой объект обновился, добавились сигналы? Дописывай биндинг (в итоге биндинг гстримера тупо не поспевает за гстримером, который в каждой ветке обновляется знатно).

Ну, это грустно. Но это, скорее, проблема того, как устроен сам биндинг. Он ведь старше интроспекции, например.

Да полно в исходниках же, игра «найди утечку»

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

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

Подцеплять Asio в какой-нибудь другой язык — бессмысленно и беспощадно.

из всех браузеров — Firefox перешёл на FFmpeg, Chrom{e,ium} перешёл на FFmpeg

Никуда они не перешли, им насрать просто. У фурифокса были биндинги к ветке 0.10, она померла, они и выкинули код. В хроме не было никогда, по-моему. Ни тот, ни другой аппаратное ускорение под линуксом не поддерживает, им насрать просто. gstreamer очень популярен в эмбедеде, на сайтах всяких техасинструментс найдешь много примеров, а разработчики разных девайсов пилят под него свои плагины.

На ffmpeg ты с него не мигрируешь, потому что это совершенно разные вещи, и ffmpeg gstreamer не может заменить в принципе.

каше из плагинов

Эм, это просто иерархия, по степени стабильности, допиленности и лицензионной свободы.

судя по его тупо сломанному API/ABI в 0.x => 1.x

Вот другие библиотеки не ломают совместимость при переходе с 0.x на стабильный 1.0? sdl1 и sdl2 полностью совместимы? Qt3 и Qt5?

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

Мне третьего дня довелось заглянуть в чужой код на C++, в котором через JNI нужно было с Java взаимодействовать (точнее, там из Java через JNI хотели использовать C++ный код с активным использованием шаблонов). Там было все как мы любим — ручное управление ресурсами, наплевательское отношение к exception safety, даже сравнение строк через strcmp. И все это не смотря на то, что у людей возможность использовать C++17.

Так там простой unique_ptr с тривиальным кастомным делетером упрощал и сокращал код в разы.

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

Да полно в исходниках же, игра «найди утечку»
https://github.com/GStreamer/gst-plugins-base/blob/master/gst-libs/gst/gl/gbm...

Так ад интеграции с плюсами где?

Так там простой unique_ptr с тривиальным кастомным делетером упрощал и сокращал код в разы.

Так сокращал (бы) или всё-таки сократил?

Так ад интеграции с плюсами где?

Там, где ты не скормишь лямбду методу, ожидающему коллбэк (а значит оборачивай данные, которые ты бы обернул в замыкание в специальную структуру, объявляй ее тип, и проч. бойлерплейт), не вызовещь deref объекта с помощью raii, не убедишься статически в типе полиморфического value и.т.д.

Так сокращал (бы) или всё-таки сократил?

Должен был бы сократить. Если люди прислушаются к выданным им рекомендациям. Обещали прислушаться :)

Вы хотите сказать, что внутри Rust-овской обертки будет что-то другое?

Там автоматизированная генерация из GObject Introspection.

Т.е. проблема в отсутствии чего-то вроде moc-компилятора, который бы по GObject Introspection сгенерировал бы необходимый C++ный бойлерплейт?

Вы хотите сказать, что внутри Rust-овской обертки будет что-то другое?

Ну естественно там типобезопасная обертка, коллбэки принимают лямбды, value обернуто в тип с параметром, который компилятор выводит, для любого объекта, унаследованного от gobject реализован трейт Drop. Там все чистенько и опрятно. У самописного биндинга к крестам тоже в принципе, но он самописный, и многие важные вещи там невозможны бай дизайн (как обращение к сигналам, которые явно не обернуты).

Ну естественно там типобезопасная обертка,

Типобезопасная обертка внутри обертки. Чего только не скажет человек, если не читает то, что ему пишут.

Мне в js нужен свой foreach (var e : arr), который будет делать тоже самое, что for (var i = arr.length-1; i; i--) {var e = arr; ...} Зачем? Чтобы не делать копипаст. Почему не for..in/for..of? Они тормозные и делают не то, что надо.

arr = [1, 2, 3]
for(let [e] of each(arr)) console.log(e)
for(let [e, i] of each(arr)) console.log(i, e)

// 3
// 2
// 1

// 2 3
// 1 2
// 0 1

Сколько стоит такое сделать?

Примерно две строки кода, это стоит.

function* each(arr){
	for(let i = arr.length; i--;) yield [arr[i], i];
}

Ну внутри там ffi, который, впрочем, генерируется. Мне-то в него лезть не надо, в крестах надо.

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

И это проблема C++.

И доказательство отсутствия библиотек для C++.

Должен был бы сократить

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

Вывод — не стоит особо доверять сослагательному наклонению. Зачастую оно обманывает ожидания.

Т.е. проблема в отсутствии чего-то вроде moc-компилятора, который бы по GObject Introspection сгенерировал бы необходимый C++ный бойлерплейт?

Ээ, нет, просто снимается большая ручная работа при подготовке релиза биндинга.
К слову, в glibmm/gtkmm далеко не всё руками делается.

Ну например что вам надо?

Qt, например.

Ну я как бы тоже не вчера код писать начал. Но когда в коде видишь что-то вроде:

jstring jname = (jstring)env->GetObjectArrayElement(arr, IDX_NAME);
const char *c_name = env->GetStringUTFChars(jname, JNI_FALSE);
... // Здесь код, который может бросать исключения.
env->ReleaseStringUTFChars(jname, c_name);

unique_c_string_t c_name{ make_unique_c_string(env, arr, IDX_NAME) };
... // Здесь код, который может бросать исключения.

struct unique_c_string_deleter_t {
   JNIEnv * env_;
   jstring jstr_;

   void operator()(const char * c_str) const noexcept {
      env_->ReleaseStringUTFChars(jstr_, c_str);
   }
};
using unique_c_string_t = std::unique_ptr<const char *, unique_c_string_deleter_t>;

unique_c_string_t make_unique_c_string(JNIEnv * env, jobjectArray arr, int idx) {
   auto jstr = static_cast<jstring>(env->GetObjectArrayElement(arr, idx));
   return {env->GetStringUTFChars(jstr, JNI_FALSE), unique_c_string_deleter_t{env, jstr}};
}

Qt… кой не предполагает использование STL вовсе %).

И как там делается? И почему получается результат, который Freyr69 не устраивает?

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

Так их нет, других популярных языков в его нише. Ну, кроме вечнозеленого Си.

jstr копируется, env — летает голым указателем

если и дальше применять такой же подход (т.е. разобраться с владением env, и дальше по цепочке), можно закопаться очень надолго.

ну и дельта конечных объёмов, как коллега заметил, не определена.

У вас в JNI методы вида:

static JNIEXPORT void JNICALL some_jni_method(JNIEnv *env, jobject that, jobjectArray arr);

ЗЫ. Можно на LOR-е сделать так, чтобы анонимные комментарии были не видны вообще? Задолбали над- и мегамозги.

И как там делается? И почему получается результат, который Freyr69 не устраивает?

Там всё сложно %).
Вот так, например, выглядит обёртка вокруг GtkButton: button.ccg, button.hg.

Никуда они не перешли, им насрать просто. У фурифокса были биндинги к ветке 0.10, она померла, они и выкинули код.

Нет они перешли: Фурифокс перешёл на ffmpeg
И наверняка потому что писать код разработчикам Firefox под наркоманскую хрень вроде GStreamer'а осточертело.

На ffmpeg ты с него не мигрируешь, потому что это совершенно разные вещи, и ffmpeg gstreamer не может заменить в принципе.

Для тех вещей, которыми оперирует браузер, того же FFmpeg'а почему-то вполне оказалось достаточно. Более того, с переходом на FFmpeg пропали дурацкие баги GStreamer'а аля: невозможно перемотать видео, невозможно изменить уровень громкости, внезапное пропадание звука и видео, квадраты во все поля, шипения ! заикания ! странные попёрдывания при переключении треков/видео и т. д.

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

Вот пускай он там и остаётся — в Embedded-мирке.

Эм, это просто иерархия, по степени стабильности, допиленности и лицензионной свободы.

Это просто беспорядок и хаос. Качество всей этой слабо связанной свалки кода GStreamer'а наглядно продемонстрировано в куче его идиотских 0-day: http://www.opennet.ru/opennews/art.shtml?num=45700

Вот другие библиотеки не ломают совместимость при переходе с 0.x на стабильный 1.0? sdl1 и sdl2 полностью совместимы? Qt3 и Qt5?

Например, у меня в системе одна версия FFmpeg, а не две. Но два GStreamer'а c разным набором плагинов. Они и в плагинах что ли API/ABI сломали, лол?