[SOLVED] Get all Objects with same class ?

gyll

there is no native C++ construct that allows you to access all instances of a class in a program

of course you can create the 'instances' list outside the class

the 'assert' statement is just a precaution to check that indeed when you delete an item from the list the list was not empty. again, it's just a precaution.

as for static members, it's simply a member of the class which is shared by all the instances of the class, and because it is not allocated for each instance it has to be instantiated explicitly (usually the most convenient place is in the cpp file of the class). if you're not familiar with static members you should either just build a separate list, or read about static members and play around with them a little to get used with them (they are pretty powerful stuff imo, so getting used with them might well be worth it)

PS
i forgot to put 'public' in my class declaration, corrected that now.

deleted28

thanks for explanation !
Yes, playing around with this is necessary :)
My CustomClass named : "KNhead"

got error in knhead.cpp: here line 12
error: undefined reference to `KNhead::instances'
knhead.h
@#include <QObject>
#include <QByteArray>
#include <assert.h>

class KNhead
{

private:

// QByteArray *intern_qba;

public:
KNhead();
~KNhead();

static std::vector<class KNhead*> instances;

QByteArray *intern_qba;

...
@

knhead.cpp
@#include "knhead.h"
#include <QDebug>

// need to instantiate this because 'instances' is static
std::vector<class KNhead*> instances;

KNhead::KNhead()
{
intern_qba = new QByteArray("Hokuspokus");
qDebug() << intern_qba->size();

instances.push_back(this);       // <<<<<<<<<<<<

}

KNhead::~KNhead()
{
// assert(instances.size());
// instances.pop_back();

}@

Maybe you see the problem immediately :)

gyll

oops, right, sorry, the line in the cpp file:
@std::vector<class KNhead*> instances;
@
should be
@std::vector<class KNhead*> KNhead::instances;
@
i.e. the instantiation should be KNhead::instances. i corrected it in the listing.

PS
And of course the 'custom.h' should #include <vector> and 'custom.cpp' should #include "custom.h", added these to the listing

deleted28

great, that was also my first suspect

As you see, i do not have experience witht Qt and C++,
but i have to create a swarm of objects and let them communicate
with the other using several rules. (maybe similar to neuronal net)
Goal is to observe mofification of this net depending on communication rules.

still a long way to go :)

gyll

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

JKSH

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?

deleted28

this is really great, thanks a lot both :)

SGaist

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

deleted28

as for KDE, right ?
but the STL also gives a cool fealing

gyll

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)

SGaist

As for every user of the Qt library

STL is a different beast

@CONFIG += c++11@

sets everything needed to use C++11

deleted28

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(&#41;;

}@

output:
@Hello

1
1
1
1
@

Is there a "static" missing ?
or do i need ust some more coffe to wake up this morning

JKSH

[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.

deleted28

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'

JKSH

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/

deleted28

Ok, now no errors and it s output looks good:
@Hello

3
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

gyll

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();
...
@

JKSH

[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
}
@

gyll

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

deleted28

@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;