C++ std::vector быстрее QVector?

Код покажи хоть. Ну и можешь попрофилировать, чтобы понять, где QVector медленнее работает и почему.

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

прошу прощения, забыл залить на гитхаб qt5 ветку, залил

основные вычислительные операции в файлах:
equity.cpp (std::vector)
handstrength.cpp (std::vector)
equity.cpp (QVector)
handstrength.cpp (QVector)

это действительно так, либо к QVector необходимо как-то по особому обращаться?

В QVector есть поддержка copy-on-write, поэтому при любом вызове неконстантного метода производится проверка, нужно ли чначала скопировать данные. Кроме того, беглый взгляд на дифф между ветками показывает, что QVector кое-где передает по значению, это значит что эти проверки могут привести и к реальному копированию

у QVector отсутствует доступ к изменяемому элементу с контролем выхода за пределы массива, как в std::vector метод at()?

Да, но в дебажной сборке выход за пределы массива контролируется ассертом

придется некоторые компоненты брать из STL

как будто есть что-то плохое в использовании стандартной библиотеки ЯП, на котором программируешь

как будто есть что-то плохое в использовании стандартной библиотеки ЯП, на котором программируешь

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

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

да, но данное действие происходит, лишь при передаче массива в разные потоки. Как реализовать данное действие без копирования я даже хз. Ведь, если передавать по ссылке, то несколько потоков будут изменять один и тот же объект, чего не должно быть по логике программы. Если передавать, как rvalue через move(), то исходник при первом вызове thread() уничтожится и остальным потокам не достанется.

at проверяет. [] - нет. Еще можешь ускорить.

В QVector есть поддержка copy-on-write, поэтому при любом вызове неконстантного метода производится проверка, нужно ли чначала скопировать данные. Кроме того, беглый взгляд на дифф между ветками показывает, что QVector кое-где передает по значению, это значит что эти проверки могут привести и к реальному копированию

Вот такая причина может быть как выше написали, а я еще хочу добавить что:

stl контейнеры достаточно примитивны, а qt-шные, вероятно более богаты ф-лом, не смотрел реализацию qt контейнеров, но возможно там много что завязано на их QVariant, что само по себе может отнимать такты процессора, но зато конечно предоставлять классную гибкость и удобства.

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

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

К сожалению сейчас не могу найти ссылку с описанием этого и там еще хорошая таблица сравнения скорости работы была, кроме этой ссылки (https://www.reddit.com/r/cpp/comments/692qhk/stditerators_vs_raw_pointers_per...) - но в этой ссылке не совсем то, но тоже про этот эффект.

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

PokerCalc-qt5$ time LD_LIBRARY_PATH=./src ./PokerCalc 
hi : 0
pairs : 3005328
sets : 726528
two pairs : 1577664
straits : 12192
flashes : 23760
fullhouses : 154368
straitflashes : 0
kares : 27360
sum_cycle : 5527200

real    0m5,375s
user    0m18,900s
sys     0m0,012s

PokerCalc-master$ time LD_LIBRARY_PATH=./src ./PokerCalc 
hi : 0
pairs : 84480
sets : 12960
two pairs : 19008
straits : 0
flashes : 0
fullhouses : 1152
straitflashes : 0
kares : 0
sum_cycle : 117600

real    0m0,077s
user    0m0,236s
sys     0m0,000s

Вывод и должен различаться или программы делают разную работу ?

У меня обычно дикая мешанина stl и qt в проекте выходит. Потому что хоть убейся, но qt контейнеры не полностью умеют move semantics. С другой стороны вызывать кутешное АПИ приходится, да и есть немного функционала в qt непокрываемого stl, например QCache.

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

Не мешало бы подтвердить свои слова о разности в скорости итерации через итераторы и указатели в release-режиме актуальными замерами. А не отсылками к тому что где-то когда-то кто-то о чем-то говорил.

ведь в общем на уровне интерфейса так сказать никто не гарантирует что даже в векторе следующий за этим элемент будет на следующем адресе

Правда? Речь все еще об std::vector?

если вдруг будут использовать нестандартный аллокатор, то так вполне может быть)

А что, вектор с кастомным аллокатором будет запрашивать отдельные блоки для каждого элемента вектора вместо одного большого блока на весь текущий capacity?

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

Сами Qt'шники стараются отказаться от многих своих велосипедов и рекомендуют использовать STL, а ты наоборот.

eao197, прошу прощения, что не в тему. Если не трудно, подскажите современные книги и прочие материалы по идиоматическому применению C++11 и новее. Спасибо.

Rust - самое идиоматическое применение C++11

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

Но, если говорить про книги, то, вероятно, классический набор отсюда: https://github.com/rigtorp/awesome-modern-cpp (раздел Books).

в мастер ветке значение количества циклов стоит не то, что в qt5, разница по ентому не такая ессесна большая, но все равно у меня она 30% при равных параметрах...

он наверна перепутал вектор с deque

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

qt не пробовал - С++ десктоп не писал. Это я к тому, что хороший qt или нет, но если надо гуй на плюсах, альтернатив тупо нет (gtk тот же qt, только менее документированный)

Это смотря что за гуй, не нужно обобщать.

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

А я как раз хочу найти неqt. Пока остановился на идее попробовать electron.

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

real    0m4,113s
user    0m14,545s
sys     0m0,020s

stl контейнеры достаточно примитивны, а qt-шные, вероятно более богаты ф-лом

да ладно, в stl-контейнерах есть куча фич, которых нет в кутешных, в частности из свежих стандартов

Но правда конечно к чему таки оптимизации, ведь в общем на уровне интерфейса так сказать никто не гарантирует что даже в векторе следующий за этим элемент будет на следующем адресе

Стандарт гарантирует

Скотт Мейерс «Эффективный и современный c++»

много кто грит, что проги на qt отличаются большой стабильностью

Лол. Стабильность проги в основном зависит от прямоты рук того, кто ее делает

да я чето не проснувшись видимо писал, действительно гарантирует.

Потому что хоть убейся, но qt контейнеры не полностью умеют move semantics

В какой версии? Можно примеры?

да ладно, в stl-контейнерах есть куча фич, которых нет в кутешных, в частности из свежих стандартов

Пробежался по векторам, не нашёл кучи.

/me не защащиет stl или Qt вектор, просто интересно, что за куча..

Во всех контенейнерах: нет emplace; нет поддержки кастомных аллокаторов (да, API STL-ных аллокаторов много критикуют, но тут вообще ничего); нет конструкторов из пары произвольных итераторов

В ассоциативных контейнерах: нет поддержки кастомизации компараторов и хэш-функций для конкретного контейнера; нет insert с итератором

Может еще что-то забыл. Во времена Qt 4 все было еще хуже, не было даже реверсных итераторов

Еще по foreach по хешу пробегает значения, а не пары. В принципе оно удобнее, но а вдруг ключ тоже нужен. Не все как я дублируют ключи в самом объекте.

Потому что хоть убейся, но qt контейнеры не полностью умеют move semantics

В какой версии? Можно примеры?

Так не работает: QVector<std::unique_ptr<int>>

QVector и другие контейнеры в Qt работают только с копируемыми типами, потому что при copy-on-write контейнер обязан уметь склонировать элементы.

и еще, у QVector отсутствует доступ к изменяемому элементу с контролем выхода за пределы массива, как в std::vector метод at()?

.value(index, default_vaue)

В принципе оно удобнее, но а вдруг ключ тоже нужен

Удобнее бывает не всегда, а в контексте range-for (foreach уже не актуален) такой финт удивляет неподготовленных людей

в stl, но не qt

а в мастер ветке, не создается либа?
qt5 ветка была выделена из мастер и потом переведена на QVector без изменений в остальном коде.

имелось ввиду, что сложно на qt чото забагать люто, сразу варнинги и ерроры летят

Караван офигительных историй!

T QVector::value(int i, const T &defaultValue) const
где же енто изменяемая ссылка?

вухаахахаха, я грю чо прочел про qt5... люди так пишут, я ж им чо

этот метод

а в мастер ветке, не создается либа?

нет, не создается

А я как раз хочу найти неqt. Пока остановился на идее попробовать electron.

Попробуй более легкую альтернативу электрону https://sciter.com/

значит буду мешать qt с STL

Вон я только что написал std::map<TileIndex, QHash<QString, std::shared_ptr<Tile>>> и доволен. Правда не все комбинации рабочие, но тут компилятор об этом вовремя сообщит.

https://sciter.com/

О, вот это уже интересно. Спасибо за ссылку. А на каком оно енжине и умеет ли flexbox и css grid?

О, вот это уже интересно. Спасибо за ссылку. А на каком оно енжине и умеет ли flexbox и css grid?

Там свой движок оптимизированный под десктоп и с аппаратно ускоренной графикой. Автор заседает в комитете W3C. В css там много специфичных для десктопа фишек https://sciter.com/docs/content/css/cssmap.html https://www.terrainformatica.com/w3/flex-layout/flex-layout.htm https://sciter.com/docs/flex-flow/flex-layout.htm Тут сравнение с браузером https://terrainformatica.com/w3/flex-layout/flex-vs-flexbox.htm

Я про stl и говорил :)

Блин, а опенсорцные аналоги у https://sciter.com/ есть?

Блин, а опенсорцные аналоги у https://sciter.com/ есть?

Вроде нет, но за деньги исходники sciter вполне доступны.

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