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

[Авварон]

Я знаю человека, он пишет на ассемблере, и "прекрасно обходится без си, с++ и не жалуется. Всё возможно." Вопрос в том, что если qtшные контейнеры по ряду причин лучше, зачем использовать std'шные? Больше нравится? Ну это не объективная причина...
Вот алгоритмы СТЛные заменить нечем, это да

Поглядел, кувектор использует меммув в некоторых случаях (isStatic != тип примитивен или movable)

QVector<T>::iterator QVector<T>::erase(iterator abegin, iterator aend)
{
...
        if (QTypeInfo<T>::isStatic) {
            // тут ручное копирование
        } else {
            destruct(abegin, aend);
            memmove(abegin, aend, (d->size - itemsToErase - itemsUntouched) * sizeof(T));
        }
...
}

Сообщение отредактировал Авварон - 13.2.2013, 22:40

[Алексей1153]

Я знаю человека, он пишет на ассемблере, и "прекрасно обходится без си, с++ и не жалуется. Всё возможно."

это он просто C++ не пробовал

Вот алгоритмы СТЛные заменить нечем, это да

да. Я раньше вручную это всё долбал, пока не познакомился с STL. Это как откровение было ))

Вопрос в том, что если qtшные контейнеры по ряду причин лучше

ЧЕМ ? Да и Qt не везде бывает

зачем использовать std'шные? Больше нравится? Ну это не объективная причина...

я пишу на C++ , этой причины достаточно. Удивляешь прям!


а теперь барабанная дробь

qtшные контейнеры по ряду причин лучше

Как в vector с помощью insert не получается

у человека - проблема с кутешным контейнером. С контейнером STL проблемы нет


Авварон, у тебя наблюдается фанатичная зомбированность. Библиотеки бывают не "лучше" или "хуже", а более подходящие или менее подходящие для решения каждой конкретной задачи

Qt-контейнеры хорошо подходят для передачи и возврата данных в/из Qt-классы/сов
STL-контейнеры хорошо подходят для хранения массивов и ассоциаций данных и работы с ними

[Авварон]

Писание на с++ - это не аргумент в пользу того, чтобы использовать стд::векторы. Нет, если вы пишите на голых плюсах, то да - там вариантов нет. Но, используя Qt, и постоянно конвертируя одни контейнеры в другие вы только снижаете производительность и портите читаемость кода. Я почти что на 90% уверен, что вы повсеместно используете итераторы "для скорости", но вас совершенно не смущают строки вида qvector.toStdVector, угадал?
Это у вас какая-то нездоровая зомбированность стд и боязнь коровы, раз вы в упор не видите ее плюсов.
А топикстартеру достаточно было заменить QVector на QList - у него есть метод аппенда списка в конец.

[Iron Bug]

эх, молодо-зелено!
если говорить про серьёзную оптимизацию по скорости, то Qt надобно выкинуть и даже не вспоминать. борьба за скорость на уровне memmove, когда в библиотеке используется софтовая шина сигналов - это просто попытка заштопать маленькую дырку в целиком рваном мешке.
Qt - отличная кроссплатформенная библиотека, для своего круга задач. она используется для написания сугубо пользовательских приложений, для которых скорость не критична (уровня миллисекунд там, как правило, хватает). это медленные приложения, имеющие дело с малыми скоростями данных, чаще всего для работы с пользователем. удобная кроссплатформенная библиотека, на которой быстро (с точки зрения написания кода) можно что-то сделать, в том числе и с графическим интерфейсом.
что касается алгоритмов: библиотек дофига! в гугле можно их найти сотни. некоторые даже кроссплатформенны: например, тот же Boost. есть дубли STL, с оптимизированной реализацией отдельных алгоритмов. так что тут жалобы беспочвенны. есть и математические библиотеки, и обработка контейнеров всех видов. практически всё, что только можно вообразить, уже давно написано.
что касается вопроса использования любого класса в STL алгоритмах - это вопрос копирования элементов и конструкторов-деструкторов (т.н. "большая тройка"). все детали описаны в документации на контейнеры. и для любого элемента их можно написать и использовать стандартные алгоритмы, если уж на то пошло. это просто шаблоны, ничего сверхъестественного в них нет.
если интересует скоростная работа с массивами данных - это intrusive контейнеры в Boost и пулы памяти. однако, вряд ли такая оптимизация понадобится для медленных пользовательских задач прикладного уровня.

[Алексей1153]

Писание на с++ - это не аргумент в пользу того, чтобы использовать стд::векторы.

или так - когда говорим на русском, нет необходимости использовать все 3 времени. Ведь есть инфинитив и жесты руками и ногами!
Ну а можно не мучаться и использовать все времена, так как они - стандарт, входящий в язык

постоянно конвертируя одни контейнеры в другие

я этого не делаю

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

ой ? Странно, производительность хорошая, читаемость тоже

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

Сообщение отредактировал Алексей1153 - 14.2.2013, 14:50

[lanz]

эх, молодо-зелено!

Ну вот, пришел лесник и всех разогнал!

[Авварон]

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

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

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

[Алексей1153]

я вот, например, не умею писать хорошо алгоритмы

обращайся, помогу

насчёт одной формочки - это, конечно, забавно

Раскрывающийся текст

1) писано в VS9 в течение нескольких лет (до сих пор поддерживается и дополняется, изначально начиналось в VS6 , потом перешёл на VS9)
npopioner.ru/products-page/programmnoe-obespechenie/avtomatizirovannoe-rabochee-mesto-guard3-obnovlenie-ot-23-01-2012g/

описание к нему
npopioner.ru/PROG/DOC_Guard.zip


2)
программатор для объектовых приборов и пультов

(тут ссылка сразу на архив. Писано это ещё в VS6. Кнопка на морде в виде белого калькулятора - список для выбора прибора - пощёлкай, зацени количестко вкладочек и элементиков )
npopioner.ru/PROG/UniProgBarier-2.zip

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

А может и повлияет - пока вы не напишите код и не прогоните его профилировщиком, вы этого не узнаете

ну да, ну да ) Без него - никак

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

1) убедить
2) научить его скачивать, устанавливать и настраивать Qt SDK и QtCreator + с Qwt чуток побарахтались.
3) привыкнуть к новой для него IDE и особенностям Qt

но, блин, теперь он видит, что я был прав, и больше не спорит. Также в процессе разработки, хотя в ТЗ некие моменты совсем по другому написаны, я несколько раз предлагал сделать иначе. Снова упирание рогом, убеждение, в конце концов он соглашается, и делаем по-моему. И он снова видит, что так действительно лучше, и теперь спорит ещё меньше. В конце концов, мне платят за то, что я делаю, я это и делаю хорошо.

Кстати, давай тебя на фрилансе зарегим ))

Сообщение отредактировал Алексей1153 - 14.2.2013, 16:35

[Авварон]

Алексей1153
По первой программе ничего не могу сказать. А вот вторую не поленился, скачал. Да, эта программа подпадает под мое понимание "одной формочки". Что у нее там внутри крутится, не могу сказать, но по количеству пунктов меню/настроек (один порт) могу сказать, что с точки зрения УИ программа очень простая; а вот начинка там может быть очень и очень сложная - я не спец в вашей области. Неудивительно, что вам нечего конвертировать в кутешные типы
Вот пример сложной программы в моей области (биржевые терминалы) http://idtrader.ru/wp-content/uploads/2010/12/quik.gif
Не уверен, что могу засветить УИ нашей разработки, но он приблизительно такой же монструозный (хотя и проще и красивее). Так что, программы разные бывают. Где-то можно вынести функционал в коре либу на голых плюсах, а где-то вся бизнес-логика зашита в уишных айтем моделях и ничего нельзя выделить, ибо нет смысла.

Про заказчика - вы молодец у нас заказчик тоже дельфятник; "я вас так понимаю"

Кстати, вот вы упомянули профилировщик - не подскажете хороший профайлер под винду? А то до сих пор я обходился маковскими Инструментами, но, при портировании на Qt5, вылезли дикие тормоза под вендой, хотелось бы поглядеть, где там кутеха тормозит.

Зачем меня регать на фрилансе?)

[Iron Bug]

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

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

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