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]

SJ wrote:

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?

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

[Victor Bazarov]

SJ wrote:

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?

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]

"SJ" <np****@hotmail .com> wrote in message
news:81******** *************** ***@posting.goo gle.com...

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

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]

"SJ" <np****@hotmail .com> wrote in message
news:81******** *************** ***@posting.goo gle.com...

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

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]

"John Harrison" <jo************ *@hotmail.com> wrote in
news:2h******** ****@uni-berlin.de:

(...)

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.

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

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

[Victor Bazarov]

John Harrison wrote:

[...]
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.

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

V

[David Harmon]

On Thu, 20 May 2004 16:53:13 +0100 in comp.lang.c++, "John Harrison"
<jo************ *@hotmail.com> wrote,

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.

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]

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

"bartek" <sp************ ******@o2.pl> wrote in message
news:Xn******** *************** ***********@153 .19.251.200...

"John Harrison" <jo************ *@hotmail.com> wrote in
news:2h******** ****@uni-berlin.de:

(...)

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.

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

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