Re: References
Andrea Crotti <andrea.crotti.0@gmail.com> wrote in
news:m18w0ybcl4.fsf@ip1-201.halifax.rwth-aachen.de:
Paavo Helde <myfirstname@osa.pri.ee> writes:
Get rid of shared data between classes and use proper encapsulation -
this will save many headaches in long turn. All data should be private
unless your class is just a bundle of unrelated stuff like std::pair.
Example:
class Packer
{
public:
Packer(int _x) : x(_x), dirty(true) {}
private:
int x;
bool dirty;
public:
void packData(char *) {
if (dirty)
// do something
dirty = false;
}
void NotifyXChanged(int new_x) {
x = new_x;
dirty = true;
}
int GetX() const {return x;}
};
class Packet
{
public:
Packer p;
void setX(int _x) {
p.NotifyXChanged(_x);
}
Packet(int _x) : p(x) {}
int GetX() const {return p.GetX();}
};
int main() {
Packet p1(10);
cout << p1.GetX() << endl;
p1.setX(3);
cout << p1.GetX() << endl;
return 0;
}
hth
Paavo
That's actually a nice idea, but what if there are many different
Packer??
In your example Packer was a member of Packet. If there are many such
members then you have to update/notify them all in Packet::setX(). If
each Packet has to take some action if x changes, then somebody will have
to tell it that x has changed, right? The simplest way is to just call
some function on each Packet. If they are all similar it might make sense
to derive them all from a common abstract virtual base class and store a
container of base class pointers. In this case the notification function
would loop over the container and call a virtual function on each object.
- which would then make the right thing depending on the actual type of
the object.
In the real code there is one Node, which has some data, and different
Packet type that can be generated from that data.
There was no Node in your example. I have no idea what your actual design
is, so I cannot really answer very specifically. In general, you have to
make up your mind which classes are holding the actual data, and which
classes are reflecting or interpreting it in some way. Maybe you will
have something like document-view model? Or then a visitor model? Can't
tell as the names like Packer and x do not say much to me.
And those Packet type can actually share some fields, so having them
inside each Packet type might be not very good.
When classes are sharing fields, this usually hints inheritance and
derived classes. But maybe you thought about objects sharing fields (via
references like in your original example)? This no-no, try to avoid this.
If something like this is needed, the shared data should be put in a
separate class which is responsible for maintaining it, and multiple
objects of other classes may contain references or pointers to a single
object of this class. This brings the reference-counted smartpointers
instantly into mind.
The actual goal is not to minimize the memory footprint of the program,
but to make a correct, robust and maintainable application (in the limits
of the budget etc). I bet having some data duplication and robust means
of synchronizing it may work out better than trying to share the common
data via references (in addition to more complex data dependencies this
may cause problems related to object lifetimes and multithreading, for
example).
I also suspect you are making the whole thing overly complicated, but
maybe your task requires it.
In this case it would be great to have ruby(or python)-like metaclasses
support, but looking on the internet looks like it's not so easy...
In C++ one uses either compile or run-time polymorphism instead of
metaclasses (i.e. either virtual functions or templates).
hth
Paavo