[SOLVED] Get all Objects with same class ?
-
oh yeah
RULE OF THUMB: DO NOT USE ANYTHING SPECIFIC TO Qt whenever you don't REALLY need to, or else you'll get an app that requires Qt, and you just never know with these open source guys, today they're here, tomorrow they're all gone. Just use plain C++, no QByteArray, no signal/slots, etc, except when you really need them, and even then TRY TO CREATE YOUR OWN CLASSES AND FUNCTIONS AS WRAPPERS over what t provides so that you can easily change the framework if you'll have to -
Hi,
[quote author="wally123" date="1422710389"]I do not know what exactly i can do with "QMetaObject"[/quote]The documentation that you linked to says that QMetaObject is "not normally required for application programming, but it is useful if you write meta-applications, such as scripting engines or GUI builders." -- you usually won't need to use it for regular programs, but it provides advanced conveniences if you ever need them.
However, QMetaObject does not give you the ability to track all instances of your custom class. You will need to implement your own tracker, like gyll said.
[quote author="wally123" date="1422710389"]I'm even suprised its not C++.[/quote]I believe gyll meant that the meta-object system is not "plain C++". QMetaObject itself is fully implemented in C++, and can be used like any other C++ class that you might create in your applications.
[quote author="wally123" date="1422714070"]
@
std::vector<class KNhead*> instances;KNhead::KNhead()
{
instances.push_back(this);
}KNhead::~KNhead()
{
instances.pop_back();
}
@
[/quote]This approach only works if you to always delete the objects in reverse order of their creation. Imagine this scenario:You create 3 objects ('A', 'B', and 'C'). They are added to your vector in this order ('A' is first, 'C' is last). If you then delete object 'B', its destructor calls pop_back(), which removes 'C' from the vector!
I suggest using an unordered set instead of a vector, and removing a specific object instead of the last object.
@
QSet<KNhead*> instances;KNhead::KNhead()
{
instances.insert(this);
}KNhead::~KNhead()
{
instances.remove(this);
}
@Or, if you want to stick to the STL:
@
std::unordered_set<KNhead*> instances;KNhead::KNhead()
{
instances.insert(this);
}KNhead::~KNhead()
{
instances.erase(find(this));
}
@[quote author="gyll" date="1422717891"]you just never know with these open source guys, today they're here, tomorrow they're all gone.[/quote]Qt has been around for 20 years, it is backed by a commercial company, and it is spreading. I highly doubt Qt will be gone in the foreseeable future.
[quote author="gyll" date="1422717891"]TRY TO CREATE YOUR OWN CLASSES AND FUNCTIONS AS WRAPPERS over what t provides so that you can easily change the framework if you'll have to[/quote]That sounds like a lot of extra work. Is it worth the effort? How often have you changed the framework of an established app?
-
this is really great, thanks a lot both :)
-
Hi,
To add to the excellent points of JKSH, you also have the "KDE free Qt foundation":https://www.kde.org/community/whatiskde/kdefreeqtfoundation.php who's purpose is to secure the availability of Qt
-
as for KDE, right ?
but the STL also gives a cool fealing -
JKSH: "I suggest using an unordered set instead of a vector, and removing a specific object instead of the last object."
OUCH, that's correct, my code is TOTALLY WRONG. you have to remove the object that you are deleting, not just the last object.
so here we go, correction:
@
// custom.h
#include <unordered_set>
class Custom {
public:
Custom();
~Custom();
static std::unordered_set<Custom*> instances;
}// custom.cpp
#include "custom.h"
#include <assert.h>
std::unordered_set<Custom*> Custom::instances;Custom::Custom() {
instances.insert(this);
...
}Custom::~Custom() {
assert(instances.count(this));
instances.erase(this);
...
}
@PS
unordered_set is C++11, so if you're using gcc you have to add to your .pro file (the Qt project file) a line like this (at least for now, until gcc parses C++11 by default):
@
QMAKE_CXXFLAGS += -std=c++11
@you can safely make the line above the first line in your .pro file
If you're using some other compiler (MSVC, llvm, whatever) then you might have to check the compiler's documentation for enabling C++11 support (i'm not sure about this, maybe QMAKE takes care of the translation, dunno)
-
As for every user of the Qt library
STL is a different beast
@CONFIG += c++11@
sets everything needed to use C++11
-
I'm sorry but i need more help.
I do not know how to work on the QSet instances.knhead.h:
@#include <QObject>
#include <QSet>class KNhead
{
public:
KNhead();
~KNhead();QSet<KNhead*> instances;
};@
knhead.cpp:
@#include "knhead.h"QSet<KNhead*> instances;
KNhead::KNhead()
{
instances.insert(this);
}KNhead::~KNhead()
{
instances.remove(this);
}@main.cpp:
@#include <QCoreApplication>
#include <QDebug>
#include <QSet>
#include "knhead.h"int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);
qDebug() << "Hello\n";KNhead *cell_1 = new KNhead; KNhead *cell_2 = new KNhead; KNhead *cell_3 = new KNhead;
// qDebug() << ??? instances.count() ??? ;
qDebug() << cell_1->instances.count(); qDebug() << cell_1->instances.size(); qDebug() << cell_2->instances.count(); qDebug() << cell_2->instances.size(); return a.exec();
}@
output:
@Hello1
1
1
1
@Is there a "static" missing ?
or do i need ust some more coffe to wake up this morning -
[quote author="wally123" date="1422779095"]Is there a "static" missing ?[/quote]Yes, your set needs to be a static variable. You want all the different KNhead instances to write to the same set, after all.
-
just put a "static" in knhead.h line 10 and knhead.cpp line 3
@
static QSet<KNhead*> instances;
@results in:
error: undefined reference to `KNhead::instances'
-
You need to define static member variables in a .cpp file somewhere. Add this line to knhead.cpp (outside of any functions):
@
QSet<KNhead*> KNhead::instances;
@Do some extra reading to understand "how to use static member variabless":http://www.learncpp.com/cpp-tutorial/811-static-member-variables/
-
Ok, now no errors and it s output looks good:
@Hello3
3
3
3@Do i need always an arbitrary instance of class KNhead to access instances
or is there another way ?e.g. qDebug() << cell_1->instances.count();
or cell_2 or cell_3 -
As i told you in my first reply (you forgot :P):
"Once you have the above, you have access to ‘instances’ anywhere in your program (provided you #include “custom.h” in the cpp files where you use ‘instances’) via name qualification: 'Custom::instances'So, in any cpp file where you want to access 'instances' just make sure to #include "knhead.h" and then just use 'KNhead::instances':
@
#include "knhead.h"
...
qDebug() << KNhead::instances.count();
...
@ -
[quote author="gyll" date="1422783535"]
@
#include "knhead.h"
...
qDebug() << KNhead::instances.count();
...
@
[/quote]It's a good idea to avoid globally-accessible variables where feasible. Currently, someone can add/remove items from the set, without constructing/destroying a KNhead!For more robust code, make the set private and implement a static member function that allows you to read the variable (but not modify it):
@
class KNhead
{
public:
static QSet<KNhead*> KNhead::instances() {
return m_instances;
}private:
QSet<KNhead*> m_instances; // Give it a different name from the function
}
@ -
w/r JKSH: using getters in the situations where you want to very clearly isolate the places where a data member changes is indeed considered the "clean code good practice" for ordinary data members, but if you have:
- you want to provide a static getter method
- you don't want to make the getter method return the actual variable because of efficiency reasons (in this particular example the getter would return a copy of the entire set each time it's called, i.e. alloc/dealloc)
then you'd need to make the getter return a reference to the variable, and you'd need to make the getter 'const'. but you can't have const qualifiers for static methods:
@
static QSet<KNhead*>& instances() const; // wrong: can't specify 'const' to static methods
@Alternatively, one could provide method wrappers for all the methods that are needed in your code in conjunction with the data member (it's the cleanest way, but it takes a bit of typing and code checking), e.g. you could have a static method instanceCount(), instanceList(), etc, and use one method or another as needed in the code (sure enough, instanceList() would still return a copy of the set, but only when the full set is actually needed e.g. for iterating through it)
PS
fwiw, i personally don't bother much with write protection (not even for ordinary data members) except when writing interfaces for objects that are to be used by "the general public"; inside the nuts and bolts my own code i just let it be -
@class KNhead
{
private:
QSet<KNhead*> m_instances;public:
KNhead();
~KNhead();// static QSet<KNhead*> instances;
static QSet<KNhead*> instances() { return m_instances; } int testProp;
};@
/knhead.h:4: error: invalid use of member 'KNhead::m_instances' in static member function
QSet<KNhead*> m_instances; -
you should have spotted the mistake yourself by now :P
there's a little error there, it should be:
private:
static QSet<KNhead*> m_instances;i.e. the member still has to be static, just as it was until now, you only added a new static getter method but everything else remains the same (static methods can only access static data members of an object).
still, i have to say it again, using getters (not to mention static getters) is in my opinion an overkill when it's not a "general public" object. If i were you i'd just use the variable 'KNhead::instances' directly where i needed it. -
If i understnad you correctly, you recomment to use this QSet<T*>
( set of gathered objects created by gather method (?) )
as public and not to use JKSH's suggestion to make it private
and not avoid globally-accessible variables for now, because
to much efforts to implement it (overkill).
Is this correct ? -
No, you are just missing the static qualifier in from of m_instances, JKSH's technique is fine
-
I set the static already and it works now.
My above question is meant to this :bq. still, i have to say it again, using getters (not to mention static getters) is in my opinion an overkill when it’s not a “general public” object. If i were you i’d just use the variable ‘KNhead::instances’ directly where i needed it.