Qt-interest Archive, July 2006
List of objects derived from QObject? How?
Message 1 in thread
I'm trying to develop a small application where I want deal with a list of
objects that belong to a class derived from a QObject class. That class
will need to use it's fair share of signals and slots.
So having this in mind, what is the best container to hold objects of that
type?
Thanks in advance
Rui Maciel
--
[ signature omitted ]
Message 2 in thread
Rui Maciel wrote:
> I'm trying to develop a small application where I want deal with a
> list of objects that belong to a class derived from a QObject
> class. That class will need to use it's fair share of signals and
> slots.
>
> So having this in mind, what is the best container to hold objects
> of that type?
The type of container depends largely on what you want to do with
the data, not what type the data is -- i.e.
- Should it be sorted?
- Will you only insert and delete at the end or insert and delete
frequently in the middle?
- Will you only read the container in full or will you search for
something frequently?
Have a look at the documentation about the Qt containers, it's IMHO
very clear.
http://doc.trolltech.com/4.2/containers.html
In this case, I like to use a QList<QObject*>. Dunno if that's the
best way to do it, but for me it works.
Regards,
Björn
--
[ signature omitted ]
Message 3 in thread
Bjoern Schliessmann wrote:
> The type of container depends largely on what you want to do with
> the data, not what type the data is -- i.e.
>
> - Should it be sorted?
> - Will you only insert and delete at the end or insert and delete
> frequently in the middle?
> - Will you only read the container in full or will you search for
> something frequently?
I'm looking for a container which enables me to store objects that need to
be connected to other QObject-derived objects and that enables me to
perform searches.
> Have a look at the documentation about the Qt containers, it's IMHO
> very clear.
>
> http://doc.trolltech.com/4.2/containers.html
Bummer. I'm still using Qt 3.3 :(
Best regards
Rui Maciel
--
[ signature omitted ]
Message 4 in thread
"Rui Maciel" <rui.maciel@xxxxxxxxx> wrote in message
news:eafia0$kpr$1@xxxxxxxxxxxxxxxxxxxxx
> Bjoern Schliessmann wrote:
> I'm looking for a container which enables me to store objects that need to
> be connected to other QObject-derived objects and that enables me to
> perform searches.
A container shouldn't enable/disable your object to do anything.
The fact that you want to do searches is the only thing relevant
to the container type that you mention here.
Maps usually have the best search complexity.
>> Have a look at the documentation about the Qt containers, it's IMHO
>> very clear.
>>
>> http://doc.trolltech.com/4.2/containers.html
>
> Bummer. I'm still using Qt 3.3 :(
3.3 has containers. Check the docs. Also,
one of my favorite things about Qt is that it
works well with std containers. You may
want to investigate std::map or std::list.
--
[ signature omitted ]
Message 5 in thread
Duane Hebert wrote:
> A container shouldn't enable/disable your object to do anything.
> The fact that you want to do searches is the only thing relevant
> to the container type that you mention here.
>
> Maps usually have the best search complexity.
That was what was bugging me. I didn't knew if storing a QObject-derived
object in a container would have an impact on the whole signals and slots
mechanism.
If there isn't any impact whatsoever then I'm free to use the good old STL
containers, right?
Thanks for the help
Rui Maciel
--
[ signature omitted ]
Message 6 in thread
"Rui Maciel" <rui.maciel@xxxxxxxxx> wrote in message
news:eafjgc$qab$1@xxxxxxxxxxxxxxxxxxxxx
> That was what was bugging me. I didn't knew if storing a QObject-derived
> object in a container would have an impact on the whole signals and slots
> mechanism.
Signals and slots work with an instance of an object. Not with the
container the object is in. The container will affect how you access
the object, sort the objects, insert/delete the objects etc.
> If there isn't any impact whatsoever then I'm free to use the good old STL
> containers, right?
I haven't had any problems with stl containers of qobjects. I imagine
there may be cases when a container going out of scope and destroying
its members may conflict with the qtobjects getting deleted by their
parent but I haven't seen this yet. You could always use a qpointer
then I guess.
--
[ signature omitted ]
Message 7 in thread
Rui Maciel wrote:
> That was what was bugging me. I didn't knew if storing a
> QObject-derived object in a container would have an impact on the
> whole signals and slots mechanism.
Imagine a container not as a container, but as an interface
to "fish" the objects you stored in it out of the memory.
In a container, the objects aren't "contained" in any way.
Containers are only there to provide automated memory management
and good searching. The objects are always accessible from the
outside (if you happen to have a pointer to them).
> If there isn't any impact whatsoever then I'm free to use the good
> old STL containers, right?
You are.
Regards,
Björn
--
[ signature omitted ]
Message 8 in thread
Rui Maciel wrtoe:
> Duane Hebert wrote:
>
> > A container shouldn't enable/disable your object to do anything.
> > The fact that you want to do searches is the only thing relevant
> > to the container type that you mention here.
> >
> > Maps usually have the best search complexity.
>
> That was what was bugging me. I didn't knew if storing a QObject-derived
> object in a container would have an impact on the whole signals and slots
> mechanism.
>
> If there isn't any impact whatsoever then I'm free to use the
> good old STL containers, right?
Of course, you can only store pointers to QObjects (or derived
classes) there, as QObjects themselves are not copiable.
But other than that: Sure, it works.
Andre'
--
[ signature omitted ]
Message 9 in thread
On 29.07.06 12:54:39, Rui Maciel wrote:
> Bjoern Schliessmann wrote:
>
> > The type of container depends largely on what you want to do with
> > the data, not what type the data is -- i.e.
> >
> > - Should it be sorted?
> > - Will you only insert and delete at the end or insert and delete
> > frequently in the middle?
> > - Will you only read the container in full or will you search for
> > something frequently?
>
> I'm looking for a container which enables me to store objects that need to
> be connected to other QObject-derived objects
That doesn't affect the choice.
> > Have a look at the documentation about the Qt containers, it's IMHO
> > very clear.
> >
> > http://doc.trolltech.com/4.2/containers.html
>
> Bummer. I'm still using Qt 3.3 :(
Well, you can still read the page and check what class is available in
Qt3.3, for example QList from Qt4 maps to QPtrList or QValueList
(depending on wether you store pointers or values).
Andreas
--
[ signature omitted ]
