[SOLVED] Get all Objects with same class ?

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;

gyll

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.

deleted28

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 ?

SGaist

No, you are just missing the static qualifier in from of m_instances, JKSH's technique is fine

deleted28

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.

JKSH

[quote author="wally123" date="1422790846"]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 ?
[/quote]Yes, that is what gyll recommended.

Both approaches work.

The global approach is the "fast" way, and saves you a few lines of code at the start
The the private approach is the "safe" way, and reduces the risk of you making mistakes in the future.

As the program designer, you need to compare the costs and benefits of the different approaches and decide which one you want.

I leave you with this piece of wisdom from xkcd:
!http://imgs.xkcd.com/comics/good_code.png(Good Code)!
(source: http://xkcd.com/844/ )

deleted28

nice !
now the Iterator ... :)