Simple class design issue, pointer to parent needed

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Jacek Dziedzic

    Simple class design issue, pointer to parent needed

    Hi!

    Say a have a class called black_box which, among other
    things, contains an array of cells like this:

    class black_box {
    private:
    // ...
    public:
    black_box_detai ls_struct details;
    cell cells[10000000]; // let's assume this is fixed to 10M
    };

    "details" is a struct that contains some information about
    the metrics of the black_box, data in this structure is
    relevant to the operation of members of the cells array.

    A cell is a tiny class itself, that stores a state (say, an int)
    and has some methods:

    class cell {
    private:
    int internal_state;
    // ...
    public:
    // ...
    void update_state();
    };

    Now... the problem is that cell::update_st ate() needs some
    information stored in black_box::deta ils (because it contains
    the information on cells partitioning, size, etc.).

    So basically it's a "how to get a pointer to parent" issue.
    I've googled a bit for a solution and found two ways to deal
    with this, one was a hack almost, using an offsetof macro
    that looked absolutely nasty and not portable. The other
    solution was to store a pointer to parent in all children.
    Obviously I can't afford storing a pointer in every cell
    because that would mean 40MB of wasted data on my
    system. I can't store a static pointer in the cell class either,
    because I could have cells in various instances of the
    black_box class that would obviously require different
    pointers.

    Is there anything I can do? I've been pondering on two
    ways to go around this...

    1) move the methods from class cell to class black_box
    and hence have something like this

    black_box::upda te_one_cell(cel l &which);

    but I feel that the cell updating method belongs more to the
    cell class than to the underlying black_box class, so I have
    some doubts.

    2) the other way I thought of was to pass a pointer to
    the relevant black_box as an extra parameter to each cell
    method, like this:

    cell::update(bl ack_box *silly_parent_p ointer);

    So... which would be better (I don't like either), or is there any
    other, more natural, workaround?

    TIA,
    - J.


  • Howard

    #2
    Re: Simple class design issue, pointer to parent needed


    "Jacek Dziedzic" <jacek-NOSPAM-@janowo.net> wrote in message
    news:31352-1066394565@jano wo.net...[color=blue]
    > Hi!
    >
    > Say a have a class called black_box which, among other
    > things, contains an array of cells like this:
    >
    > class black_box {
    > private:
    > // ...
    > public:
    > black_box_detai ls_struct details;
    > cell cells[10000000]; // let's assume this is fixed to 10M
    > };
    >
    > "details" is a struct that contains some information about
    > the metrics of the black_box, data in this structure is
    > relevant to the operation of members of the cells array.
    >
    > A cell is a tiny class itself, that stores a state (say, an int)
    > and has some methods:
    >
    > class cell {
    > private:
    > int internal_state;
    > // ...
    > public:
    > // ...
    > void update_state();
    > };
    >
    > Now... the problem is that cell::update_st ate() needs some
    > information stored in black_box::deta ils (because it contains
    > the information on cells partitioning, size, etc.).
    >[/color]

    How about passing a pointer to the black_box_detai ls_struct in your
    update_state call? That's the info you said you need, so it's what you
    should pass.

    -Howard





    Comment

    • Jakob Bieling

      #3
      Re: Simple class design issue, pointer to parent needed

      "Jacek Dziedzic" <jacek-NOSPAM-@janowo.net> wrote in message
      news:31352-1066394565@jano wo.net...[color=blue]
      > Hi!
      >
      > Say a have a class called black_box which, among other
      > things, contains an array of cells like this:
      >
      > class black_box {
      > private:
      > // ...
      > public:
      > black_box_detai ls_struct details;
      > cell cells[10000000]; // let's assume this is fixed to 10M
      > };
      >
      > "details" is a struct that contains some information about
      > the metrics of the black_box, data in this structure is
      > relevant to the operation of members of the cells array.
      >
      > A cell is a tiny class itself, that stores a state (say, an int)
      > and has some methods:
      >
      > class cell {
      > private:
      > int internal_state;
      > // ...
      > public:
      > // ...
      > void update_state();
      > };
      >
      > Now... the problem is that cell::update_st ate() needs some
      > information stored in black_box::deta ils (because it contains
      > the information on cells partitioning, size, etc.).[/color]


      I would go for Howard's suggestion, if the 'black_box' class is the only
      one doing the calls. If the client code is calling 'update_state' on a cell
      (which I think is possible), then I can imagine this is pretty much just as
      'ugly' as your second solution.

      You might consider restructuring the design a bit. You move the actual
      'internal_state ' variables into 'black_box' as a private int array
      (replacing the 'cell' array) and let 'black_box' have a member function
      called 'get_cell' or similar:

      cell_proxy get_cell (size_t idx);

      As the name suggest, you only return a proxy object, which will get all
      neeeded information upon construction and thru which you can do all
      manipulation. The proxy object basically does the same as you current 'cell'
      class, except that the actual data is stored in 'black_box'. A decent
      compiler should optimize it so you will have no difference in speed.

      hth
      --
      jb

      (replace y with x if you want to reply by e-mail)


      Comment

      Working...