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