Russian Qt Forum
Май 17, 2024, 19:34 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало Форум WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  
  Просмотр сообщений
Страниц: 1 ... 710 711 [712] 713 714 ... 761
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.
Код:
s1 += "a";
И получаем все прелести копирования по значению - по полной программе.
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) этого нет  Улыбающийся
Страниц: 1 ... 710 711 [712] 713 714 ... 761

Страница сгенерирована за 0.102 секунд. Запросов: 23.