Cloudflare выпустила первый публичный релиз Pingora v0.1.0

берешь gdb версию бинаря с дебажными символами и начинаешь дебажить.

В расте только дебаг собирать?

Так это одно и то же.

Нет, это зависит от библиотеки.

Т.е паника может быть отключена в релиз версии настройками при сборки. Что бы не было «спасибо» и пошли балду пинать. Есть крейты log и log4rs (и другие аналоги). Где мы, как умные программисты, будем обрабатывать все Result и Option, а вместо a[9999999]=… использовать match a.get_mut(99999){ Some(…) =>{….},None=>{….}}

Так это одно и то же.

Конечно же нет) Если надо корки мучить, то с сишке собирается релиз с дебажными символами (-O2 -g для примера), который бережно храниться. Стрипается, чтобы дебажных символов не было в релизе (man strip), и отправляется юзеру.

Есть крейты log

Вот только логи не сильно помогут в случае сегфолта, когда программа остановилась и буферы не скинуты. К тому же их еще надо расставить где надо.

мы, как умные программисты, будем обрабатывать

Что могу сказать) Если на Си писать правильно, то ошибок тоже нет))))

Причём тут идеоматика языка? И то и другое — библиотеки.

Паника отключается в настройка - принудительно программистом. Если не отключить минимальный выхлоп мы получим. А кордамп операционка сама делает

Что за бред? Это самая обычная библиотека.

Ну так и в расте так же.

О точно, с 1.57 появилось. Давно я ржавого не щупал) Так глядишь на нем скоро можно будет нормально кодить))

В смысле, доводить код до корок?

В смысле, в прод отправлять без проблем)

Нет, это зависит от библиотеки.

Преобразований между std::string и QString и std::list и QStringList не избежать.

То есть, там, где в питоне я просто пишу:

widget.addItems(lib.data())

в С++ приходится писать что-то вроде

widget.addItems(toQStringList(lib.data()))

и так на всех стыках между моделью и отображением.

Конечно же нет) Если надо корки мучить, то с сишке собирается релиз с дебажными символами

Теперь понял. Неоднозначность термина «дебаг».

Вот оптимизированный с дебажными символами в раст:

[profile.release-with-debug]
inherits = "release"
debug = true

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

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

А разве для Qt уже не требуется компиляция через moc?

так как даже для вывода через printf эту строку сначала придётся копировать

Нет конечно:

printf("%.*s", str.len, str.p);

Да, был неправ, преувеличил.

«Стандартная библиотека» C++ уродлива. Любое игнорирование её существования надо поощрять.

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

Или вместо единого Си++ множество подъязыков: Qt, VTK, MFC, ROOT, … для каждого из которых нужна своя реализация алгоритма.

Не нужно. Все умеют работать с const char*. И все реализации предоставляют возможность получить указатель на нультерминированную строку.

И много кто использует, например, не std::string, а QString, boost::container::string и т.п.

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

И все реализации предоставляют возможность получить указатель на нультерминированную строку.

И как его получить из QString, например?

Судя по https://wiki.qt.io/Technical_FAQ#How_can_I_convert_a_QString_to_char.2A_and_vice_versa.3F только через копирование всей строки. Причём двойное, если нужно время жизни после временной переменной.

Поэтому в том месте, где Qt ты с большой вероятностью сможешь построить приложение только из самого Qt

Вот поэтому я и считаю Qt де-факто отдельным языком.

А ну сейчас нельзя стало, видимо. Еще один минус из кармы Qt.

В рамках «языка Qt» это логичное решение. Строка там изменяемый массив юникодных символов. Если хранить постоянно char* в UTF-8, то на s[0] = c возможно придётся переписывать всю строку, если старое значение первого символа и новое использует разное количество байтов в UTF-8.

О! Начинает доходить, насколько UTF-8 «замечательная кодировка».

Сам Юникод «замечательный». Потому что понятие символа напрочь убито. И особой разницы нет, пишешь ты кодопоинт от 1 до 4 байт в UTF-8 или от 1 до 2 байт в QString. Символ всё равно может состоять из произвольного числе кодопоинтов или, наоборот один кодепоинт может описывать несколько символов, а значит его изменение может заставить переписывать всю остальную строку.

Для этого придумали слово «фреймворк».

Фреймворки бывают идиоматическими (которые можно использовать совместно с базовой библиотекой и друг с другом) и неидиоматическими (как Qt в C++).

К слову, в Python основанный на Qt PySide является идиоматическим: в нём нет своих версий строки и коллекций, которые уже есть в базовом языке. И не требуется отдельного синтаксиса для сигналов и слотов (для слота есть декоратор).

Фреймворки бывают идиоматическими (которые можно использовать совместно с базовой библиотекой и друг с другом) и неидиоматическими (как Qt в C++).

Ты это деление сам только что придумал?

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

Qt использует свой препроцессор, но все еще преобразуется в обычный плюсовый код.

Я больше про NIH-синдром на все базовые типы.

Когда в питоне можно писать

table.setHorizontalHeaderLabels(["Name", "Hex Code", "Color"])

а в C++ надо собирать через

QStringList horzHeaders;
horzHeaders << "test1" << "test2" << "test3";
table.setHorizontalHeaderLabels(horzHeaders);

В Common Lisp такой же hu.dwim есть. Вроде библиотека, но при использовании любого кусочка надо тащить почти весь фреймворк и при использовании свои описания пакетов и классов.

Посмотри на прототипы в Qt - увидишь кучу стыкующихся функций с обычными плюсовыми типами.

Ага. Эдакий FFI к остальному Си++.

NIH-синдром на все базовые типы

Это не NIH, а вполне оправданная унификация компонентов, чтобы не использовать тысячу и один каст. 99% всех кейсов при работе со строками и списками отлично покрываются Qt. Плюс строки в кишках используют неявное кеширование, чтобы экономить память.

а в C++ надо собирать через

table.setHorizontalHeaderLabels(QStringList() << "test1" << "test2" << "test3");

Слава богу, Qt делали умные люди.

table.setHorizontalHeaderLabels({«test1», «test2», «test3»});

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

Вот есть libyue. Идиоматичная библиотека графического интерфейса. Где строки — это std::string, строки таблицы выбираются через std::set, а не QTableWidgetSelectionRange, пометка текста делается двумя числами, а не через QTextCursor.

Qt использует свой препроцессор, но все еще преобразуется в обычный плюсовый код.

Чего-чего? Его обычный g++ компилирует.

Раньше вроде moc требовался. Или g++ научился «signals:» и «slots:» понимать?

Научился… по крайней мере ошибку не пишет.

Потому что это библиотека гуев, а не фреймворк.

У меня всё еще через moc собирается.

А в основе scoped_refptr

Раньше вроде moc требовался. Или g++ научился «signals:» и «slots:» понимать?

И сейчас требуется. signals: он не понимает, ты видимо goto метку создал.

в С++ приходится писать что-то вроде

std::for_each или range-based-for спасут отца русской демократии от необходимости приводить коллекции (кутешные, кстати, под стд мимикрируют на ура). Останется только тип внутри, тут варианта три:

• страдать и приводить явно

• вкорячить какой модный std::views::transform

  for (auto item : input | std::views::transform([](auto &s) { return QString::fromStdString(s); }))
  

• страдать и приводить в некоторых случаях неявно (например, char * будет захватываться в QString без необходимости явного приведения).

table.setHorizontalHeaderLabels({"test1", "test2", "test3"});

upd а выше монку ответили такое же (:

кутешные, кстати, под стд мимикрируют на ура

Как QStringList передать в f(vector<string> & v)?

table.setHorizontalHeaderLabels({«test1», «test2», «test3»});

Да, для непосредственного ввода в Си++ много магии прикрутили. Я имел в виду, что в питоне можно передать стандартный список строк. А в C++, если уже есть vector, приходится через transform (два раза копируем данные каждой строки).

Проблема с приведением больше не синтаксическая, а алгоритмическая. Если мы берём Си++, значит нам важна производительность, а на границе Qt и остального Си++ мы получаем накладные расходы такого же порядка, как между Си++ и питоном.

Например, если у нас есть QSqlQuery, какой-то алгоритм, преобразующий очень большой vector<tuple<string, string, int>> в другой маленький vector<tuple<string, string, int>> и вывод этого результата в QTableWidget, то для скорости работы придётся либо выкидывать QSqlQuery и заменять на что-то, что даст сразу пару std::string и число (типа pqxx), либо переписывать алгоритм, чтобы он мог работать с структурой из двух QString и int.

алгоритм, преобразующий очень большой vector<tuple<string, string, int>> в другой маленький vector<tuple<string, string, int>>

Точно такие же проблемы возникнут, если у нас на руках только array<wstring>, и тут уже начинаются вопросы к кодеру алгоритма, а почему, собственно, такой ограниченный интерфейс?

а почему, собственно, такой ограниченный интерфейс

А какой интерфейс должен быть? Вот есть алгоритм, который что-то делает с набором элементов, каждый из которых — две строки и целое число. Какой API предложишь?