How can a Static member function know all instances?

[SJ]

Hi:
I have a class which has a static member function. The function
implements something common to all instances.
How can the static member function know all of the (Get access to the
instances' handles) instances?

Thanks in advance for any help

[Jeff Schwab]

Re: How can a Static member function know all instances?

SJ wrote:
[color=blue]
> I have a class which has a static member function. The function
> implements something common to all instances.
> How can the static member function know all of the (Get access to the
> instances' handles) instances?[/color]

In the constructor of your class, have each instance register itself in
a static table.

[Victor Bazarov]

Re: How can a Static member function know all instances?

SJ wrote:[color=blue]
> I have a class which has a static member function. The function
> implements something common to all instances.
> How can the static member function know all of the (Get access to the
> instances' handles) instances?[/color]

The usual implementation is a container of instance pointers as a static
data member of a class. Make sure you add to that list in every
constructor (thus you will have to re-implement all implicit ones), and
remove from that list in the destructor.

V

[John Harrison]

Re: How can a Static member function know all instances?


"SJ" <npeasy@hotmail .com> wrote in message
news:81bdc69b.0 405200739.3e497 74c@posting.goo gle.com...[color=blue]
> Hi:
> I have a class which has a static member function. The function
> implements something common to all instances.
> How can the static member function know all of the (Get access to the
> instances' handles) instances?
>
> Thanks in advance for any help[/color]

Something like this?

class X
{
X() { instances.inser t(this); }
X(const X& rhs) { instances.inser t(this); ... }
// all other ctors similarly

~X() { instances.erase (this); }

static std::set<X*> instances;
static void some_func()
{
for (std::set<X*>:: const_iterator i = instance.begin( ); i !=
instances.end() ; ++i)
{
X* inst = *i;
// do something with inst
}
}
};

A hash table would probably be a better structure than a std::set.

One issue that occurs to me is that the compiler is allowed to optimise away
a copy constructor even if that copy constructor has a side effect. Not sure
if that is an issue here since I can't recall the circumstances in which
this is allowed to happen.

john

[Howard]

Re: How can a Static member function know all instances?


"SJ" <npeasy@hotmail .com> wrote in message
news:81bdc69b.0 405200739.3e497 74c@posting.goo gle.com...[color=blue]
> Hi:
> I have a class which has a static member function. The function
> implements something common to all instances.
> How can the static member function know all of the (Get access to the
> instances' handles) instances?
>
> Thanks in advance for any help[/color]

It can't. Not directly, anyway. Static member functions can only access
static member data.

If you're doing something common to all instances, then that should probably
be done by manipulating static member data. Static member data is located
in one place only, not in every instance of the class, so there should be no
need to gain access to all existing instances. They all share the same
static data.

If what you're doing is manipulating some common data value, upon which
individual instances then make *other* calculations (to their own,
non-static, member data), then one solution is to use accessor functions in
the class for the non-static member data. Then, when you ask for one of
those calculated values, you can actually calculate it at that time from the
static data that the static function previously changed.

Or, if there is some reason that you *really* need to access all existing
instances of a class from a static function, then you'll need to somehow
register each instance with a container of some sort, and iterate through
the container to access those instances.

-Howard

[bartek]

Re: How can a Static member function know all instances?

"John Harrison" <john_andronicu s@hotmail.com> wrote in
news:2h42crF8q6 b2U1@uni-berlin.de:

(...)
[color=blue]
> One issue that occurs to me is that the compiler is allowed to
> optimise away a copy constructor even if that copy constructor has a
> side effect. Not sure if that is an issue here since I can't recall
> the circumstances in which this is allowed to happen.[/color]

In case of direct RVO probably.
Shouldn't be a problem whatsoever, should it?

--
:: bartekd [at] o2 [dot] pl

[Victor Bazarov]

Re: How can a Static member function know all instances?

John Harrison wrote:[color=blue]
> [...]
> One issue that occurs to me is that the compiler is allowed to optimise away
> a copy constructor even if that copy constructor has a side effect. Not sure
> if that is an issue here since I can't recall the circumstances in which
> this is allowed to happen.[/color]

Mostly it's for return value optimization and pass-by-value optimization,
I believe.

V

[David Harmon]

Re: How can a Static member function know all instances?

On Thu, 20 May 2004 16:53:13 +0100 in comp.lang.c++, "John Harrison"
<john_andronicu s@hotmail.com> wrote,[color=blue]
>One issue that occurs to me is that the compiler is allowed to optimise away
>a copy constructor even if that copy constructor has a side effect. Not sure
>if that is an issue here since I can't recall the circumstances in which
>this is allowed to happen.[/color]

The compiler is allowed to optimize away the creation of a temporary
value, even if that implies eliminating a constructor call with a side
effect. But, if the compiler finds it necessary to create the object,
then the constructor must be called. Works fine for the purpose of
registering all the objects created.

[Dave Townsend]

Re: How can a Static member function know all instances?


Speaking RVO , in this situation, there would be the elimination of a
destructor call too,
so the net effect is none.

"bartek" <spam.will.eat. itself@o2.pl> wrote in message
news:Xns94EFBFC B21B44bartekdqw ertyuiopo2p@153 .19.251.200...[color=blue]
> "John Harrison" <john_andronicu s@hotmail.com> wrote in
> news:2h42crF8q6 b2U1@uni-berlin.de:
>
> (...)
>[color=green]
> > One issue that occurs to me is that the compiler is allowed to
> > optimise away a copy constructor even if that copy constructor has a
> > side effect. Not sure if that is an issue here since I can't recall
> > the circumstances in which this is allowed to happen.[/color]
>
> In case of direct RVO probably.
> Shouldn't be a problem whatsoever, should it?
>
> --
> :: bartekd [at] o2 [dot] pl
>[/color]