вставка QVector в другой QVector Опции

[__ilya__]

Как вставить один вектор в конец другого.
Как в vector с помощью insert не получается

 
vector<t> v0, v1, v2;
//
//
v0.insert(v0.end(), v1.begin(), v2.end());

как-то так можно со стандартным вектором. С QVector не получается, пишет -нет такого прототипа
использую Qt4.8

Сообщение отредактировал __ilya__ - 10.2.2013, 22:54

[Авварон]

Iron Bug
То есть ваша позиция - если в либе есть одна медленная часть (сигнал-слоты), то можно на производительность остальных частей забить? Окей... Я бы не хотел с вами в команде работать

Теперь, какие моменты нужно действительно оптимизировать: такие, которые действительно сказались на производительности. Один вызов qvector.toStdVector (его вызывать никогда не приходилось, кстати) перед долгим циклов вычислений не будет заметен совсем. Затем: всё, что касается GUI оптимизировать по скорости вообще не требуется (но и тут разумность нужна - 5 секунд после нажатия кнопки юзера не устроят). Это так получается само собой - реакция человека гораздо медленнее любого разумного лага "производительности". И там можно не задумываясь хоть 10 раз вызвать qvector.toStdVector! Это ни на что не повлияет

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

[Iron Bug]

Iron Bug
То есть ваша позиция - если в либе есть одна медленная часть (сигнал-слоты), то можно на производительность остальных частей забить? Окей... Я бы не хотел с вами в команде работать

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

а теперь ещё немного ликбеза:
любая надстройка или библиотека, по определению, не ускоряет, а замедляет работу кода. ваш кэп.
кроссплатформенность чаще всего его тоже замедляет: надо чем-то жертвовать для поддержки разных платформ и разных систем. не бывает прибавки в скорости, когда начинается унивесализация.
Qt - далеко не та библиотека, которую тщательно оптимизировали по скорости. она не для этих целей создавалась. и она хороша, но для своего круга задач. например, по скорости тот же Boost гораздо мощнее. но он не нравится новичкам, которым бывает трудно в нём с ходу разобраться, и в нём нет графических модулей, потому что это не прикладная библиотека, а тестовый полигон для стандартизации С++. есть ещё математические библиотеки от Intel - замечательнейшая вещь! есть библиотеки для работы с MPI. вот это настоящая оптимизация. но она, опять же, чаще всего зависит от платформы.
ну и, кроме библиотек, есть ещё простые методы оптимизации вручную. этого никто не отменял. алгоритмы, Кнут и математика. плюс знание работы процессоров и операционных систем. мне просто часто с этим приходится сталкиваться. ни один компилятор не может оптимизировать код так, как это может сделать человек. и тут надо просто применять мозг, никакая автоматизация и библиотеки не помогут. это требует очень хорошего, глубокого и детального знания как тонкостей языка, так и особенностей используемого компилятора.
но, к счастью для программистов, с реальной оптимизацией они сталкиваются крайне редко. в 99.9% случаев тонкая оптимизация - это просто излишество и никто не заморачивается. медленных миллисекундных реакций системы за глаза хватает для большинства задач ПО. юзер таких интервалов не замечает, да и система не особо напрягается: процы стали мощными и многоядерными, появились множественные сопроцессоры, быстый обмен с памятью, кэширование данных на винтах, GPU и многое другое. в общем, чтобы нагрузить комп, надо ещё очень постараться. поэтому в последние годы никого особо не волнует тщательная оптимизация ПО для обычных компов. эти вопросы встают в ядрах OS, во встроенных RTOS системах, в микроконтроллерах, в автоматизации с риалтаймом. вот там это в полный рост и очень важно. а на юзерских PC на это можно смело забить (до определённой разумной степени, конечно, как правильно заметил Алексей1153). пока юзер не жужжит - програмист не чешется. обычно выбирают некий компромисс между скоростью разработки и степенью оптимизации и затраченным на это ресурсам.