QT и stl в одном проекте, приводить ли все к единообразию.

С чего вы взяли, что речь идет о стандартной библиотеке шаблонов?

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

У вас дефектный модуль определения из контекста попался? Сочувствую. Вероятность примерно такая же, как то, что при написании PASCAL на русском форуме по программированию имеют в виду библиографическую базу данных. Не нулевая, но стремящаяся к нулю.

Я про:

    std::string text = "1";

    std::vector<std::string> v;
    // v.push_back(text);
    // or
    v.emplace_back(std::move(text));

    text.push_back('2'); // UB?

    std::cout << text << ' ' << v[0] << std::endl; // 2 1

Я вообще хз что должно быть в данном случае, но clang выдаёт 2 1 для emplace и 12 1 для push. Хотя они делают одно и то же в данном случае.

Делают они не одно и то же. Внезапно, замена на v.push_back(std::move(text)); даст 2 1

Qt даёт больше гарантий

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

У тебя у самого каша в голове :) emplace и move совершенно ортогональные вещи, в push_back так-то тоже можно засунуть передвинутый объект, начиная с c++11. Emplace – это способ избежать дополнительного копирования, когда объект создаётся сразу в области памяти контейнера.

Вам бы это, с C++ бы завязать бы пора и никогда на C++ не возвращаться. Ибо emplace_back он не о том, о чем вы подумали. А вот для чего:

using namespace std;

struct some_complex_data {
    string f1_;
    string f2_;
    string f3_;
    some_complex_data(string f1, string f2, string f3)
        : f1_(move(f1)), f2_(move(f2)), f3_(move(f3))
    {}
};

int main() {
    vector<some_complex_data> v;
    v.emplace_back("1", "2", "3"); // emplace construct
    v.push_back(some_complex_data{"4", "5", "6"}); // construct then move
    some_complex_data another{"7", "8", "9"};
    v.push_back(another); // copy.
}

А вы в своем примере точно такой же UB можете получить и при использовании push_back, ибо начиная с C++11 в std::vector есть push_back, который получает rvalue reference.

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

То-то я смотрю, как баттхертящие за квиктайм ничего не поняли из контекста.

v.emplace_back(std::move(text));
text.push_back('2'); // UB?

Кстати, не UB (undefined behaviour). Там есть требование, что после std::move обьект будет в «valid, but unspecified state». Т.е. в такой ситуации компилятор таки не имеет права убить твою собаку.

Под «одно и тоже» я подразумевал это:

      void
      push_back(value_type&& __x)
      { emplace_back(std::move(__x)); }

      template<typename... _Args>
        void
        emplace_back(_Args&&... __args);

Это stl из gcc.

Пример про use after move.

Вам бы это, с C++ бы завязать бы пора и никогда на C++ не возвращаться.

Как только появится аналог Qt - сбегу и никогда не буду оборачиваться.

А вот для чего

Я знаю для чего он. Но это не мешает использовать его не по назначению и огрести проблем.

не гарантирует в контейнерах безопасность исключений

Потому, что не использует их? Или как?

Там вопросительный знак не просто так стоит. Я хз UB это или нет, но на выходе получаем мусор.

Не, то же не претензия. Просто отвечаю на тот самый знак вопроса.

но на выходе получаем мусор.

... но в валидном состоянии :D

Как только появится аналог Qt

«Будь мужиком — сделай сам!»

Я знаю для чего он.

Да-а-а??? Что ж тогда такой бред несете?

Но это не мешает использовать его не по назначению и огрести проблем.

Это вообще-то C++, а не Java. И даже не Rust, тут мозги постоянно нужно включать, ибо многое из C++, использованное не по назначению, чревато проблемами.

Однако, рекомендация использовать push_back вместо emplace_back просто дабы не было проблемы use after move, это мощно. Внушаить.

«Будь мужиком — сделай сам!»

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

Это вообще-то C++, а не Java. И даже не Rust, тут мозги постоянно нужно включать

Спасибо. Я найду куда применить свои мозги, вместо попыток не выстрелить себе в ногу в C++.

Ибо меньше не получится, в одиночку.

А вы начните, если реально многим не хватает родного GUI для какого-нибудь Rust-а, то помощники подтянутся. Может быть даже фокус с двойной лицензией, как у Qt, пройдет.

вместо попыток не выстрелить себе в ногу в C++.

Не отстреливать себе ноги в современном C++ совсем не сложно. Но если не дать себе труд разобраться чем emplace_back отличается от push_back, то сложно конечно. Тем более, когда мозги задействуются для выплескивания бреда на LOR-е.

в самом Qt, кстати, используется std::vector в некоторых местах

А вы начните

Я в курсе ваших представлений о GUI, спасибо. Тем более его уже и так пилят, conrod называется. Так вот там за пару лет работы, фактически пары человек, и почти 2000 коммитов - ничего. Это даже не альфа. Просто наброски, которые ещё ничего не умеют.

Как ругать Qt - так все тут как тут, а как оценить сложность задачи - так все разбегаются.

Не отстреливать себе ноги в современном C++ совсем не сложно.

Я эти бредни слышу в каждой теме про раст: «C/C++ такие же безопасные, как и rust, ибо у нас тоже есть умные указатели». Уровень этих граждан угадать не сложно.

Я в курсе ваших представлений о GUI, спасибо.

Уверяю, вас, совершенно не в курсе.

Я эти бредни слышу в каждой теме про раст: «C/C++ такие же безопасные, как и rust, ибо у нас тоже есть умные указатели».

Вы либо опять бредите, либо же приписываете мне то, чего я не говорил.

Фактически не используется:

./testlib/qtesttable.cpp:    typedef std::vector<Element> ElementList;
./testlib/qtesttable.cpp:    typedef std::vector<QTestData *> DataList;
./widgets/widgets/qwidgetlinecontrol_p.h:    std::vector<Command> m_history;
./corelib/doc/snippets/code/src_corelib_tools_qvector.cpp:std::vector<double> stdvector;
./corelib/doc/snippets/code/src_corelib_tools_qvector.cpp:std::vector<double> stdvector = vector.toStdVector();
./corelib/doc/snippets/code/src_corelib_tools_qhash.cpp:inline uint qHash(const std::vector<int> &key, uint seed = 0)
./corelib/doc/snippets/code/src_corelib_tools_qhash.cpp:inline uint qHash(const std::vector<int> &key, uint seed = 0)
./corelib/kernel/qmetatype.h:struct IteratorOwner<std::vector<bool>::const_iterator> : IteratorOwnerCommon<std::vector<bool>::const_iterator>
./corelib/kernel/qmetatype.h:        return **static_cast<std::vector<bool>::const_iterator*>(*iterator) ?
./corelib/kernel/qmetatype.h:    static const void *getData(const std::vector<bool>::const_iterator& it)
./corelib/kernel/qmetatype.h:struct ContainerAPI<std::vector<T> > : CapabilitiesImpl<std::vector<T> >
./corelib/kernel/qmetatype.h:{ static int size(const std::vector<T> *t) { return int(t->size()); } };
./corelib/kernel/qmetatype.h:Q_DECLARE_SEQUENTIAL_CONTAINER_METATYPE(std::vector)
./corelib/kernel/qmetatype.cpp:    std::vector and std::list containers also have built-in support.
./corelib/tools/qvector.h:    static inline QVector<T> fromStdVector(const std::vector<T> &vector)
./corelib/tools/qvector.h:    inline std::vector<T> toStdVector() const
./corelib/tools/qvector.h:    { return std::vector<T>(d->begin(), d->end()); }
./corelib/tools/qvector.cpp:/*! \fn QVector<T> QVector<T>::fromStdVector(const std::vector<T> &vector)
./corelib/tools/qvector.cpp:/*! \fn std::vector<T> QVector<T>::toStdVector() const
./corelib/tools/qvector.cpp:    Returns a std::vector object with the data contained in this QVector.
./corelib/tools/qhash.cpp:    std::vector<int>:
./corelib/tools/qhash.cpp:    std::vector<int>:
./corelib/tools/qhash.cpp:    This takes advantage of the fact that std::vector lays out its data
./dbus/qdbusargument.cpp:    as \c {std::list}, \c {std::vector}, etc.
./dbus/qdbusargument.cpp:    \c {std::vector}, etc.
./concurrent/doc/src/qtconcurrent-index.qdoc:        \li QList, QVector, std::vector

Уверяю, вас, совершенно не в курсе.

То есть это не вы сравнивали imgui с Qt?

Вы либо опять бредите, либо же приписываете мне то, чего я не говорил.

Что вы сразу о себе любимом. Перечитайте что я писал.

То есть это не вы сравнивали imgui с Qt?

Сравнил. В том ключе, что для определенных условий imgui будет удобнее/выгоднее/дешевле Qt. Например, одно из условий: интенсивное отображение информации (особенно текстовой) в GUI-приложении.

Тем не менее, я не говорил, что предпочту imgui Qt или какому-то другому фреймворку всегда вне зависимости от условий.

Что вы сразу о себе любимом. Перечитайте что я писал.

Так вы же со мной разговариваете. Поэтому не нужно приплетать в разговор чьи-то чужие бредни про то, что «С++ такой же безопасный, как Rust из-за наличия умных указателей».

Мой поинт в том, что в современном C++ не так уж и сложно не отстреливать себе ноги. Если для вас это все-таки сложно, поскольку вы не даете себе труда разобраться в том, что делаете и чем пользуетесь, тогда это ваши проблемы. Как в примере выше по поводу emplace_back и use after move.

Например, одно из условий: интенсивное отображение информации (особенно текстовой) в GUI-приложении.

Что останавливает выводить текст в Qt в 60FPS? Qt очень быстро рисует.

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

С ним и спорю. Легко. То, что вы потратили 20 лет (грубо), на изучение C++ не делает его простым, ибо компилятор не даёт никаких гарантий, в отличии от.

То, что вы знаете наизусть все грабли C++, не делает его безопасным.

Что останавливает выводить текст в Qt в 60FPS?

Например то, что любой текст внутри Qt должен быть представлен как UCS-2.

То, что вы потратили 20 лет (грубо), на изучение C++ не делает его простым, ибо компилятор не даёт никаких гарантий, в отличии от.

Еще раз: я не утверждал, что C++ простой.

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

То, что вы знаете наизусть все грабли C++, не делает его безопасным.

Уверяю вас, что знаю только малую часть граблей. Тем не менее, ноги не отстреливаю. Поскольку прежде, чем что-то брать, нужно разобраться. Выяснить, чем отличается emplace_back от push_back-а совсем не так сложно, как вам кажется. Но если вы и этого не осилили, тогда лучше вам на чем-то другом программировать.

Например то, что любой текст внутри Qt должен быть представлен как UCS-2.

И?

Тем не менее, ноги не отстреливаю.

Вы - может и нет. Всё остальные - да.

И?

Простите, все время забываю, что вам нужно объяснять элементарные вещи. Накладные расходы на преобразование из OEM в UCS-2 при интенсивном потоке текстовых данных слишком высоки.

Всё остальные - да.

Отучаемся говорить за всех.

...сдетонировал...

Заставил улыбнуться.

Накладные расходы на преобразование из OEM в UCS-2 при интенсивном потоке текстовых данных слишком высоки.

Не представляю объем текста, который нужно конвертировать дольше 16мс.

Отучаемся говорить за всех.

Достаточно в багтрекеры C/C++ проектов глянуть.

Не представляю объем текста, который нужно конвертировать дольше 16мс.

Да вы, очевидно, много чего себе не представляете.

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

Достаточно в багтрекеры C/C++ проектов глянуть.

В контексте разговора про сложности безопасного использования C++ очень умно говорить о «C/C++».

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

Ну уж извините, что не могу подняться до высот ваших мыслей.

Ну уж извините, что не могу подняться до высот ваших мыслей.

Да вы и разницы между emplace_back и push_back не можете понять. И Python у вас в два раза моложе C++...

Давайте попробую для альтернативно одаренных объяснить: если консоль для отображения телеметрии обрабатывает и отображает данные, поступающие с темпом 1-2-3K/sec, будучи написанной на Qt потребляет хотя бы на 30% больше ресурсов, чем такая же консоль, но написанная на голом нативном API, то Qt не есть хороший выбор. Ибо придется делать оптимизации, которые не нужно делать в случае тонких (хоть и функционально бедных) оберток над нативным API.

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

А вот с этим у Qt не все хорошо, как и с расходом памяти.

Да уж, рассказывайте мне как всё плохо. С нативом конечно не потягаешься, но никак сильных проседаний не будет. В том числе и по памяти, если у вас конечно нет ограничений на 16МБ ОЗУ. Qt всё же для десктопа и современных SOC.

1-2-3K/sec

Ну и конечно же есть необходимость отрисовывать текст именно 3к/сек?

Да уж, рассказывайте мне как всё плохо. С нативом конечно не потягаешься

Шиза?

Выкинуть Qt. Я бы кроме гуя на Qt ничего не писал, и его строго изолировал бы от ядра приложения, ибо нефиг. Из плюсов: можно будет при необходимости прикрутить другой GUI, а так же просто сподвигнет лучше продумать архитектуру.

В общем почитал все и решил ничего не делать, т.к. это нерациональная блажь.

Потому, что не использует их? Или как?

Нет, как в понятии «exception safety»

Если верить вики, то Qt даёт No-throw guarantee. Ведь исключение при аллокации отловить можно.