Simple class design issue, pointer to parent needed

[Jacek Dziedzic]

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_details_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_state() needs some
information stored in black_box::details (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::update_one_cell(cell &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(black_box *silly_parent_pointer);

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

TIA,
- J.

[Howard]

"Jacek Dziedzic" <ja***********@janowo.net> wrote in message
news:31**************@janowo.net...

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_details_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_state() needs some
information stored in black_box::details (because it contains
the information on cells partitioning, size, etc.).

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

-Howard

[Jakob Bieling]

"Jacek Dziedzic" <ja***********@janowo.net> wrote in message
news:31**************@janowo.net...

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_details_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_state() needs some
information stored in black_box::details (because it contains
the information on cells partitioning, size, etc.).

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)