How to create multiple instances of a static members?
Andreas Pakulat
apaku at gmx.de
Sat Feb 11 21:15:16 GMT 2006
On 12.02.06 02:05:46, kitts wrote:
> On Sunday 12 February 2006 01:33 IST, Andreas Pakulat wrote:
> > > Then static is the right choice and I don't understand your problem.
> > >
> > > Actually, the way i was looking at it was that; within one process, i
> > > have one or more sets of a class's objects. Within each of these sets i
> > > want some static objects that remain common to all, however, i do not
> > > want these static members across sets.
> >
> > There's no real "static" objects needed in what you describe. static
> > members (either variables or functions) are needed if your class
> > provides functionality that is not bound to a specific instance.
>
> I don't think i understand that fully. How would i maintain information of
> say, how many instances are present in one set?
By creating a class that "resembles" a set, for instance a class called
"Set" with add, find, take, ... methods.
> and if a member variable
> were updated by any one instance, the same be reflected in all other
> instances.
That depends on where this member variable "lies", i.e. if it is a
member of the set-class or one of it's content-classes.
For the first one, you can emit a signal in the Set-Class which is
connected to each object that is in the set during the add-Method. Your
add-Method of the Set-class would be something like
void Set::add(MyClass* o)
{
connect(this, SIGNAL(fooChanged()), o, SLOT(updateBar()));
list->append(o);
}
Now whenever the variable "foo" changed you'd emit fooChanged and all
objects in the set are notified.
> all this while each instance does not directly know of the
> others existence?
That's what loose coupling with signals/slots is for.
> May be i need to read a lil more on basic concepts.
>From what you said until now, I'd suggest a good book on Object-Oriented
programming. However I don't really know a good one.
Also this is becoming an extremely OT thread, so maybe we should discuss
this further in private...
Andreas
--
You would if you could but you can't so you won't.
-
to unsubscribe from this list send an email to kdevelop-request at kdevelop.org with the following body:
unsubscribe »your-email-address«
More information about the KDevelop
mailing list