10666
|
Qt / Model-View (MV) / Re: Помогите организовать мигание иконки внутри делегата
|
: Февраль 07, 2010, 22:37
|
Не вдаваясь в конкретные подробности реализации:
1) Расслабиться. Задачка простая - значит и решаться должна просто
2) Таймер завязать на таблицу (а не на ячейку) - это однозначно. А вдруг кто-то еще захочет мигать?
3) Таблица получает сигнал от таймера и передает его выбранной ячейке (может строке/столбцу) - а та уж знает что с ним делать (по умолчанию - ничего), простой virtual, хорошо подходит множественное наследование
|
|
|
10667
|
Qt / Общие вопросы / Re: Нитки и очередь
|
: Февраль 07, 2010, 20:41
|
А QtConcurrent не пробовали? Он вроде автоматом подбирает оптимальное число тредов . . .
С числом ниток проблем нет. По поводу QtConcurrent: насколько я понимаю, он обеспечивает различные средства блокировки/защиты, но не ф-ции "диспетчера" задач. Сейчас я на OpenMP (Intel компилятор) и вполне доволен результатами. Хотя работы очень много (никакая библиотека "распараллеливать" за меня не будет)
|
|
|
10668
|
Компиляторы и платформы / Linux / Re: Мониторинг (hotplug) устройств в *.nix?
|
: Февраль 07, 2010, 19:27
|
Почему при компиляции приложения компилятор требует библиотеку Б ? Так и должно быть? И что нужно сделать чтобы не требовал?
Насколько я понял, компиляция у Вас проходит, что-то говорит только линкер. Да, так быть должно. Компилятору нужны только описания ф-ций библиотеки (обычно заголовочные файлы). При создании статической библиотеки линкер также промолчит: нет каких-то ф-ций - ну и нет, статическая библиотека за это не отвечает. Но линкер не создаст приложение (исполняемый файл) если не обнаружена хотя бы 1 используемая ф-ция/переменная. Конечно все либы должны быть в наличии при линковке приложения.
|
|
|
10669
|
Qt / Общие вопросы / Re: приведение типов
|
: Февраль 03, 2010, 18:24
|
Давайте не путать "приводить тип" и "конвертировать". То что показал BRE правильно и будет работать но это никакого отношения к "приведению" не имеет, просто из одного контейнера копируется в другой, имеете 2 контейнера. "Приведение" означает использование физически тех же данных но с др.типом. Привести можно так typedef std::vector <char> TVec; std::vector <unsigned char> theVec; ... TVec * theUVec = (TVec *) &theVec;
// или так TVec & theUVec = (TVec &) theVec;
или то же самое но "по теории" TVec * theUVec = static_cast<TVec *> (&theVec);
Но смотрится это неважно Как сказал kuzulis, проще и лучше приводить данные "по месту", напр. char с = (char) theVec[0];
|
|
|
10670
|
Qt / Общие вопросы / Re: Соглашения по стилю написания кода в Qt
|
: Январь 31, 2010, 15:59
|
Из плюсов итераторов. ..
Из минусов итераторов...
Я согласен со всем что Вы написали, но, на мой взгляд это не главное для производительности. Если надо что-то просто просмотреть/перебрать, то проходит все что угодно и не видно особой разницы между std::vector, QVector, QList и просто "С" массивом (который все же самый быстрый ). Проблемы начинаются когда большие объемы данные "прибывают" и с ними надо что-то делать (часто при этом удалять старые). Вот тут уже разница между QVector и QList может быть в несколько раз. Другой случай - всякие хитрые просмотры/анализы с целью избежать прямого перебора. У меня есть такая задача связанная с делением BSP. Есть желание - обсудим в "алгоритмах".
|
|
|
10671
|
Qt / Общие вопросы / Re: Соглашения по стилю написания кода в Qt
|
: Январь 31, 2010, 04:35
|
Похоже на то. Значит компилятору фиолетово какую конструкцию ты используешь, один хрен соптимизирует.
Для простых конструкций - да. В ++библии приводится 2 варианта, примерно таких // первый for (i = 0; i < num; ++i) dst[ i ] = src[ i ];
// второй while (src < end) *dst++ = *src++;
И говорится что нормальный компилятор сделает примерно одинаковый код. Изучение кода - дело гораздо более полезное чем это кажется на первый взгляд. Попробуйте заглянуть в код напр "QString = ". Это не так уж трудно, совсем необязательно разбирать все "до команды". И, может быть, Вы увидите по-новому те вещи которые давным-давно знали
|
|
|
10672
|
Qt / Общие вопросы / Re: Как Qt работает с памятью и вообще про память
|
: Январь 31, 2010, 02:11
|
Ну вот, запутали человека, а потом еще и накричали на него 1) У каждой thread (нитки) свой стек, выделяется OS'ом. Как он его выделяет - его личное дело, знание этих подробностей ничего практически не дает. 2) Наукообразные выражения типа "Выделение памяти на стеке" (так же как и "стековая память быстрее") - сбивают с толку, можно подумать что это что-то типа new. В действительности все "выделение" сводится к одной команде, а "освобождение" - к другой sub esp, 8 // "выделить" 8 байт на стеке ... add esp, 8 // "освободить" их
Пусть регистр esp указывал на какой-то адрес, напр 100 (условно конечно, реальный адрес смотрится типа 0xABD00F00). Вычли из esp 8, теперь esp = 92. Значит, в байтах [92..99] можно что-то хранить. Если еще потребуется - опять вычтем из esp (стек растет в сторону уменьшения адресов). Ясно, до тех пор пока не исчерпаем стек. Когда мы добавили к esp - используемые байты никуда не делись - просто их может теперь использовать следующий "вычитающий". Раньше была классная программа Turbo Debugger - там это все было видно живьем.
|
|
|
10673
|
Программирование / С/C++ / Re: Вызов методов через не валидные указатели.
|
: Январь 25, 2010, 18:41
|
Раз в стандарте написано, что поведение не определено, значит может быть всё, что угодно.
Это где там такое написано про ф-цию член? Например компилятор для отладки вставит код проверяющий валидность результата operator->.
Нереально добавить проверку на каждое обращение по указателю. И вызов ф-ции члена никакого отношения к этому не имеет: a->getIt() означает просто getIt(a). Да, "a" плохой, так что его на стек нельзя помещать? Или выкинет строку a->getI(); после A * a = 0;, зная, что нулевой указатель можно только сравнивать, но не разименовывать. С какого перепугу? Короче: "учи матчасть"
|
|
|
10674
|
Qt / Общие вопросы / Re: Работа с контейнерами - терзают сомненья
|
: Январь 24, 2010, 00:19
|
C++ (Qt) struct Test { ... }; QVector<Test> buildVector() { QVector<Test> vec; // Заполняем вектор return vec; } void func() { QVector<Test> v = buildVector(); }
Я утверждаю, что в этом коде не будут копироваться данные находящиеся в векторе и издержки при таком использовании будут такими же, как и при использовании ссылок (или указателей). Я полностью согласен с Вашим утверждением, но это не имеет никакого отношения к Qt контейнерам, ни к Qt вообще. Все то же самое будет работать с std::vector или просто с любым классом (даже и не контейнером). Как объяснил Rcus такая оптимизация встроена практически во все современные компиляторы. Для строки QVector<Test> v = buildVector(); выполнится один конструктор и ни одного деструктора QVector. Однако нет никаких оснований обобщать этот частный случай. Напр. попробуем присвоить еще раз ... v = buildVector();
И "увы" - мы имеем вызванный деструктор (для возвращенного объекта) + оператор присваивания, который примерно = конструктор + деструктор
|
|
|
10675
|
Qt / 2D и 3D графика / Re: QPainter на QGraphicsView
|
: Январь 23, 2010, 21:44
|
Если Вам даже удастся его уговорить (не знаю как) - то все равно рисование НЕ из метода paintEvent - это хороший способ нажить себе кучу проблем. Я бы делал "легально", примерно так
- нужно отрисовать по мышe - вызываю repaint, но перед этим ставлю флаг напр. modeDrawMouse
- в перекрытом paintEvent смотрю - если есть modeDrawMouse, то мне не надо рисовать примитивы, не надо чистить background и.т.п. - надо только рисовать необходимое (часто xor)
|
|
|
10676
|
Программирование / С/C++ / Re: Вызов методов через не валидные указатели.
|
: Январь 23, 2010, 21:27
|
Не понял юмора - а почему это не должно работать и при чем здесь оптимизация? class A { public: int getI() { return 100; } };
A * a = 0; a->getI(); Значит в действительности вызовется ф-ция getIt(a) - ф-ция член, значит подается this как доп. параметр. Ф-ция this не использует - ну и нет crash. Вот если бы она была виртуальной - тогда бы получили (и то не всегда )
|
|
|
10677
|
Qt / Общие вопросы / Re: Работа с контейнерами - терзают сомненья
|
: Январь 23, 2010, 21:14
|
Но, на самом деле, для Qt-контейнеров это не так важно. Если возвращать по значению, то копирования самих данных все равно происходить не будет.
Давайте на примерах struct Test { double a, b, c, d; char data[256]; }; QVector <Test> vec; vec.resize(10); Test t1 = vec[0]; // (a, b, c, d, data) будут скопированы
Др. пример struct Test { double a, b, c, d; }; QVector <QString> vec; vec.push_back("text"); QString s1 = vec[0];
Да, действительно, сама строка "text" копироваться не будет (пока s1 не изменена), не будет и выделения памяти при присваивании. Не будет и освобождения в деструкторе. Но ведь QString еще много чего имеет кроме самих данных ("text") - и все эти члены класса будут скопированы в s1. А это ну никак не скорость возврата по указателю/ссылке. Ну и конечно, все это только до первой модификации s1. И получаем все прелести копирования по значению - по полной программе.
|
|
|
10678
|
Qt / Общие вопросы / Re: Работа с контейнерами - терзают сомненья
|
: Январь 22, 2010, 21:57
|
Я могу вернуть указатель на данные, но не будет ли правильнее вернуть сами данные ?
Правильнее то как нужно в задаче Возвращая "сами данные" Вы тем самым вызываете их копирование (и последующее удаление). А это совсем недешево, особенно для сложных данных. Если Вы делаете это намеренно/осознанно (да, здесь нужна копия) - на здоровье. А иначе надо использовать константные указатели и/или ссылки. Разработчики Qt сначала потрудились и реализовали все классы-контейнеры с механизмом Implicit Sharing.
Механизм Implicit Sharing (или shallow copy) встроен в конкретные классы, контейнеры сами по себе ничего не решают. Например: QString умеет создавать "быстрые копии" QVector <QString> vec; .. QString s = vec[0]; // это не выделяет память (пока) .. } // здесь вызовется деструктор s который сработает быстро (если s не менялось)
А std::string не умеет QVector <std::string> vec; .. std::string s = vec[0]; // выделение памяти и копирование данных (+ время) .. } // деструктор s освобождает память (+время)
Т.е. тот же самый контейнер может давать очень разную производительность в зависимости от "начинки". Поэтому объекты этих классов можно спокойно возвращать из функций и никакого оверхеда это не вызовет.
"Никакого" - это для языков типа Clipper, с которого, возможно, Вы начинали Расходы все равно будут и для скоростных задач они все равно неприемлемы. Др. дело что они будут намного меньше по сравнению с "копированием в лоб" напр. как в STL. Здесь конечно, Qt смотрится посильнее.
|
|
|
10679
|
Qt / Общие вопросы / Re: Работа с контейнерами - терзают сомненья
|
: Январь 21, 2010, 21:30
|
и вообще можно ти делать такие функции, которые будут приниматть или возвращать контейнеры, не является ли это плохим стилем ?
Хотя делать такие ф-ции не запрещено, это является плохим стилем (и не стоит смотреть/уповать на то что Qt это частенько делает). Память будет освобождена (как обсуждалось выше) но ценой выполнения очень многих действий, в Вашем конкретном примере Вы погасили скорость выполнения в несколько раз без всякой необходимости. По классике это звучит примерно так: Настоятельно рекомендуется передавать структуры по указателю/ссылке, хотя это и связано с потенциальными ошибками
Это совсем нетрудно и никак не диннее, например: void addValue( QVector<int> & vec ) { vec << 10 << 11 << 12; }
|
|
|
10680
|
Qt / Работа с сетью / Re: Qt 4.4.3 msvc2008 QDataStream лишние 2-4 байта
|
: Январь 18, 2010, 21:39
|
ахахахх)) да) но я что-то тут же на форуме читал с проблемой пересылки более 40 кб, так что 32бита наверное слишком.
Ну если следовать этой логике то пакеты/файлы больше 40К передаваться не должны Да хотя бы в Вашем же примере: разве QString не может быть больше 64K? те есть сохранить позицию до seek(0)? а почему имеено так, ведь непонятно куда указывает позишн, мошт там единичку надо вычесть, всё-таки block.size() более ориентировано на решение подобной проблемы, или вы знаете что-то что не знаю я))) Я не знаю ничего "особенного". Ну хотя бы тот же Photoshop - как он пишет свой psd файл? Да точно так же как и десятки др. хороших программ: просто IFF свободная спецификация. Общий формат - ID тега - число байт в теге - сами байты/данные Подробности уже писал здесь http://www.prog.org.ru/topic_10681_0.htmlПомимо прочего это дает возможность "старой" версии программы читать "новые" файлы т.к. их можно просто обойти (пропустить неизвестный тег и читать дальше). Ну правда в талмуде (Assistant) этого нет
|
|
|
|
|