QVector / QList проблем при използването им със потребителски класове
-
@pecuna91
Защо използваш QVector, а не QList? Не, че е важно, но ми е любопитно.
И как не ти позволява да го използваш? Грешки ли дава? Ако - да, какви?
Кода в github даваше грешки при компилирането във функцията Task::Task(const Task &obj) в "task.cpp".
Първо - трябва да се използва obj.getName() вместо *obj.getName() , защото това е reference, а не указател.
И второ - когато използваш "const Task" можеш да извикваш само функции членове от тип const. Затова промених в "baseobject.h"
QString getName();
на
QString getName() const;
Така се компилира, но нямах време да пускам програмата. -
@Stoyan
Ами свикнал съм да ползвам вектори, не съм разглеждал QList какви възможности/ограничения има.
Грешките с QObject::connect са:
error: no matching function for call to 'QObject::connect(QTimer*&, const char [11], Service*, const char [17])'
QObject::connect(timer,SIGNAL(timeout()),this,SLOT(SchedulerCall()));и другата
C:\Qt\5.5\mingw492_32\include\QtCore\qobject.h:213: error: no type named 'Object' in 'struct QtPrivate::FunctionPointer<const char*>'Промених както каза функцията в baseobject и copy конструктора в task.cpp, компилира се и тръгна, но отново дава segmentation fault при изпълнение push_back и изхода от qDebug() на copy конструктора.
Същия резултат се получава със заместване на QVector с QList.ПП: Ако си на Windows в RUN трябва да добавиш аргумент -e за да се стартира сървиса в нормален режим.
-
@pecuna91
Чак сега забелязах, че в дефиницията на класа Service липсва макроса Q_OBJECT.
Той трябва да присъства в началото, ако искаш да използваш този клас със специфичните възможности на Qt - event loop и системата "сигнал-слот" (част от нея е и connect).
Така:
class Service : public QtService<QCoreApplication>
{
Q_OBJECT
public:
...
}
Ако се наложи може да включиш в началото и:
#include <QObject> -
Това ми е ясно и съм го пробвал също. Грешката при добавяне на макроса е:
error: undefined reference to `vtable for Service'Тя темата вече се измества по-скоро към проблема с контейнера (QVector или QList) . Таймерът е подкаран в друг клас.
-
@pecuna91
Кода от github тръгва, но първо не може да прочете файла "options.xml" като QDomDocument.
След това изобщо не намира други xml файлове от папка "Tasks". Така, че изобщо не стига до изпълнението на задачата.
Все пак имам едно предложение. В GlobalVars::loadTask вместо:
Task *newtask = new Task();
newtask->setName(propelement.attribute("name"));
Task *thetask = newtask;
qDebug() << " task name: " << thetask->getName();
tasks.push_back(Task(*thetask));
да използваш това:
Task newtask;
newtask.setName(propelement.attribute("name"));
qDebug() << " task name: " << newtask.getName();
tasks.append(newtask);
(append е същото като push_back) -
@Stoyan
Качил съм в гитхъб липсващите файлове, които трябва да се копират в билд директорията.
Направих промените, но отново проблемът е при използването на вектора/списъка.
Като tasks.append(Task(newtask)); поне докарва до дебъга в Копи конструктора. -
@pecuna91
Оказа се много просто. Трябва да размениш два реда. Това:
GlobalVars globalVars;
QList <Task> tasks;
става това:
QList <Task> tasks;
GlobalVars globalVars;
Просто tasks се използва в класа GlobalVars и гърми, защото не е дефинирана.Ако ще използваш параметри от тип Task изглежда е по-добре да се използва QVector.
Но можеш да направиш tasks от вида:
QList <Task*> tasks;
т.е. списък от указатели. -
@Stoyan
Благодаря за помощта.
Успешно тръгна програмата след тази простичка размяна.
Проблемът сега се появи при разкоментиране на QVector < Trigger> triggers в tasks.h. Създадох копи,дефолтен конструктор и оператор = в Trigger класа, но се чудя дали няма проблем заради това че Trigger наследява QObject. -
@pecuna91
Какъв все пак е проблема? Не си качил променената версия и не виждам къде и как използваш triggers.Не би трябвало наследяването на QObject да е проблем. Но аз си мисля, че е по-добре по-сложните класове да се пазят в списъци и масиви като указатели. Така ще си спестиш и разправиите с copy конструктор и допълнителни оператори. Освен това ще избегнеш дублирането на данните.
Но това е мое мнение. Не съм разглеждал подробно структурата на програмата ти и е по-добре сам да прецениш. -
@Stoyan
Обновил съм хранилището.
Дефинирах QVector < Trigger*> triggers в базовия клас понеже се усетих че и Task и Operation имат този вектор като атрибут.
Пооптимизрах Copy конструкторите да ползват operator= за съответния клас, и да се избегне писането на един и същи код два пъти.
Проблемът сега е с разкоментирването на
triggers.push_back(obj);
на 182 ред в baseobject.cpp във функцията
int BaseObject::actionTriggers(QString Action, const Trigger *obj)Не ми е ясно как стоят нещата със добавянето във вектора указател към обект.
-
@pecuna91
Все още не е обновено. В baseobject.cpp в момента има само 88 реда.Идеята с указателите е да се дефинира например така:
QList<Task*> tasks; // или QVector<Task*> tasks;
(Виж в документацията на Qt в кои случаи се препоръчва използването на QList и в кои - на QVector.)
След това зареждането на задачите ще стане така:
Task *newtask = new Task();
newtask->setName(propelement.attribute("name"));
tasks.append(newtask); // или tasks.push_back(newtask);Използването на tasks става така:
QString taskname = tasks.at(i)->getName(); // или tasks[i]->getName();В момента използваш copy конструктор, но не изтриваш междинните обекти, които си създал с Task *newtask = new Task(); и те си остават в паметта.
Ако остане както досега, ще трябва да ги изтриеш с delete newtask;
Ако се използва списък с указатели, не трябва да ги изтриваш след добавяне, а чак когато се изтриват (премахват) от списъка. -
@Stoyan
Хмм, обнових го наново.
Значи по дебъг логването в конзолата виждам, че се вика Task Destructor след като се излиза от функцията, така че явно обекта се самоизтрива.
Идеята ми е евентуално тригерите да са във вектор/списък от указатели, понеже се предполага че те ще са най-много на брой.
Но как ще стане тяхното използване? Сега съм направил и класът Trigger да наследява и Runnable.
Идеята ми е как трябва да е дефинирана функцията void setTrigger(const Trigger &obj) , за да може в нея да се сетва/делийтва тригер от вектора/списъка? И след това как ще се подава аргумента
tasks.at(k).setTrigger(obj) ли? -
@pecuna91
Да. Така, както си го променил се изтрива, защото вече само го дефинираш. Така създаденият обект се унищожава щом програмата излезе извън блока, в който е дефиниран. Преди ги създаваше с new и тогава не се изтриваха.Не мога да разбера връзката между Task, Operation и Trigger. Изглежда, че всяка задача има по няколко операции, а всяка операция съдържа по няколко тригера, но последното не виждам да си го дефинирал никъде. Къде трябва да се четат и задават тригерите?
Имам едно предложение. За времето на разработката изключи използването на service и разглеждай програмата като обикновено конзолно приложение. Така е много по-лесно за debug-ване. Когато се увериш, че всичко работи както трябва, лесно можеш да я пуснеш като service отново.
Това става лесно. Направи main() да изглежда така:
int main(int argc, char *argv[])
{
QCoreApplication app(argc, argv);
GUIServer *guiserver;
qDebug() << "\n\tService started!";
if (QSslSocket::supportsSsl())
{
qDebug() << "\tSSL is supported";
}
else
{
qDebug() << "\tSSL is not supported! \n\tCheck if Openssl libraries are present.";
}
guiserver = new GUIServer();
guiserver->StartServer(QString(globalVars.getOption("Server Port")).toInt());
QString s = "password123";
QByteArray hash384 = QCryptographicHash::hash(s.toLocal8Bit(),QCryptographicHash::Sha3_384);
qDebug() << "HASH 3_384: " << hash384.toHex();
if (!guiserver->getServerrunning())
{
qDebug() <<"\n\tExiting Service.";
return 1;
}
app.exec();
} -
@Stoyan said:
Не мога да разбера връзката между Task, Operation и Trigger. Изглежда, че всяка задача има по няколко операции, а всяка операция съдържа по няколко тригера, но последното не виждам да си го дефинирал никъде. Къде трябва да се четат и задават тригерите?
Всяка задача и операция има вектор от тригери, които могат да я стартират впоследствие. Задават се във всеки обект при зареждането му, като трябва да могат и да се променят във всяко едно време от клиентската част. През определен период от време се проверяват тригерите и ако условието е изпълнено връща ок за изпълнение на задачата/операцията.
Най-вероятно ще ми трябва Scheduler да бъде наследник на QOBject за да мога да ползвам connect, но нещо пак не иска.scheduler.cpp:-1: error: undefined reference to `vtable for Scheduler'Добавил съм Q_OBJECT Макрото и промених конструктора.
Програмата се стартира като конзолно приложение с добавяне на
-e
в Run arguments .
Каква е разликата с нормална конзолна програма и сървис с -е ? -
@pecuna91
Тази грешка се появява когато си добавил макроса Q_OBJECT. При компилирането не се е изпълнила командата qmake, както би трябвало. Трябва да я пуснеш ръчно като цъкнеш с десен бутон на проекта и избереш "Run qmake". При мен така се компилира.По принцип не би трябвало да има разлика, ако се пусне и като service с аргумент "-e", но при мен така даде грешка:
The service could not be executed. ()
can't find linker symbol for virtual table for `Service' value
Когато преместих съдържанието на функцията start() в main(), както ти писах, тръгна и даде такъв резултат:
SSL is supported
Server Listening on port: 1234
"stopped"
Task is disabled
"stopped"
Task is disabled
....Предполагам, че има някакъв проблем при свързването с външната библиотека за поддръжка на service.
Преди време правих една програма, която трябваше да работи като service и използвах ето този компонент:
https://github.com/qtproject/qt-solutions/tree/master/qtservice
Ако го добавиш като подпроект няма да има нужда от външни библиотеки, защото се включва в изпълнимия файл. -
@Stoyan
АБсолютния същия проект ползвам. Можеш да видиш QtService папката във сорсовете. Библиотеката съм я добавил за да нямам допълнителни cpp файлове и да се компилира по-бързо програмата. Добавил ли си
QtSolutions_Service-head.dll файла в release директорията?Благодаря за "run qmake", досега каквото съм добавял и правил наследник на QObject винаги е тръгвало без ръчно изпълнение на тази команда.
Успеях да преместя таймера при сървис класа.
Остава въпросът как точно ще се пушват новите тригери във вектора на обекта.
Успях да го направя , но искам да е с копи конструктор или оператор = , a не с функция setAll(const Trigger &obj), което е същото де. -
@pecuna91
Даваше грешка, само когато се компилира в Debug режим. В Release работи. Предполагам, защото във файла на проекта си задал винаги да се зарежда библиотеката QtSolutions_Service-head.dll, която е за Release. При компилиране за Debug трябва да се зарежда библиотеката QtSolutions_Service-headd.dll.Доколкото виждам зареждането на тригерите става с функциите loadOperationTrigger() и loadTaskTrigger(), а добавянето в съответната задача или операция - с BaseObject::actionTriggers(QString Action, const Trigger &obj).
Ако се използва списък с указатели, аз предлагам последната функция да стане:
int BaseObject::actionTriggers(QString Action, Trigger *obj)
а още по-добре е да я разделиш на две функции:
{
addTrigger(Trigger * trigger);
delTrigger(Trigger * trigger);
В тях се включва:
triggers.append(trigger); // в addTrigger() - добавя указания тригер в списъка на текущия обект (Task или Operation)
triggers.removeAll(trigger); // в delTrigger() - премахва указания тригер от списъка на обекта.
После ги извикваш така:
Trigger * trigger;
trigger = new Trigger();
trigger->id = ...;
trigger->type = ...;
...
task.addTrigger(trigger); // или operation.addTrigger(trigger); -
@Stoyan
По този начин сетвам тригерите да.
Функцията искам да е една, еднотипна за всичките обекти.
Проблемът сега се явява отново Segmentation fault при извикване на get някой атрибут на тригер извън globalvars класа. Например в servicе или Scheduler. Понеже понякога /в редки случаи/ не го дава предполагам че е отново реда на създаване на обектите и сетването им. Можеби ще трябва да въведа някакви паузи докато се инициализират нещата,
Интересното е че не излизат атрибутите на тригерите когато ги викам с гетерите в друг клас извън GlobalVars и гърми с грешката. -
BaseObject::actionTriggers в момента изпълнява две съвсем различни неща и ще бъде по-ясно ако ги разделиш в отделни функции, но естествено не е задължително. А функциите, които предложих addTrigger() и delTrigger() пак са в основния клас и са едни и същи и за задачите и за операциите.
А за грешките - ще трябва да качиш промените, за да видя какви са и как се получават.