How can a Static member function know all instances?

Discussion in 'C++' started by SJ, May 20, 2004.

  1. SJ

    SJ Guest

    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
     
    SJ, May 20, 2004
    #1
    1. Advertising

  2. 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
     
    Victor Bazarov, May 20, 2004
    #2
    1. Advertising

  3. SJ

    Jeff Schwab Guest

    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.
     
    Jeff Schwab, May 20, 2004
    #3
  4. "SJ" <> wrote in message
    news:...
    > 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.insert(this); }
    X(const X& rhs) { instances.insert(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
     
    John Harrison, May 20, 2004
    #4
  5. SJ

    Howard Guest

    "SJ" <> wrote in message
    news:...
    > 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
     
    Howard, May 20, 2004
    #5
  6. SJ

    bartek Guest

    "John Harrison" <> wrote in
    news::

    (...)

    > 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
     
    bartek, May 20, 2004
    #6
  7. 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
     
    Victor Bazarov, May 20, 2004
    #7
  8. SJ

    David Harmon Guest

    On Thu, 20 May 2004 16:53:13 +0100 in comp.lang.c++, "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.


    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.
     
    David Harmon, May 20, 2004
    #8
  9. Speaking RVO , in this situation, there would be the elimination of a
    destructor call too,
    so the net effect is none.

    "bartek" <> wrote in message
    news:Xns94EFBFCB21B44bartekdqwertyuiopo2p@153.19.251.200...
    > "John Harrison" <> wrote in
    > news::
    >
    > (...)
    >
    > > 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
    >
     
    Dave Townsend, May 21, 2004
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. 0to60
    Replies:
    4
    Views:
    543
    jeffc
    Nov 21, 2003
  2. Replies:
    6
    Views:
    331
    Victor Bazarov
    Aug 13, 2005
  3. aling
    Replies:
    6
    Views:
    506
    Xiaobin.Huang
    Oct 30, 2005
  4. dolphin
    Replies:
    3
    Views:
    1,402
    Pete Becker
    Dec 5, 2007
  5. Andries

    I know, I know, I don't know

    Andries, Apr 23, 2004, in forum: Perl Misc
    Replies:
    3
    Views:
    281
    Gregory Toomey
    Apr 23, 2004
Loading...

Share This Page