Re: Designing a generic data holder class

On Thu, 23 Jul 2009 15:21:54 -0700 (PDT), "freesoft12@gmail.com"
<freesoft12@gmail.com> wrote:


This kind of thing often results from a kind of
..NET/Java/scripting-language mindset. C++ doesn't fit this pattern,
and you may well need to learn different design patterns, depending on
exactly what you're trying to achieve. That said...

Everything depends on what you mean by "any class".

If the classes all share a base class, you save base-class pointers in
the std::vector. Ideally, you ensure the base class has a sufficiently
large set of (presumably abstract) methods so that you can call
base-class methods rather than manually determining the run-time type.
This is by far the most common case. Common errors include failing to
define a virtual destructor for the base class, and failing to
consider whether the Node class is responsible for deleting the
instances referenced in the std::vector - does it "own" those
instances, or is it just referencing them.

That is...

  class Attrib_Base_T
  {
    public:
      virtual ~Attrib_base_T ();
        // NEVER miss this destructor off unless you
        // REALLY know what you're doing

      virtual Attrib_Base_T* Copy () const = 0;
        // Explained later

      ...
  };

  // Derived attribute classes...

  class Node_T
  {
    public:
      ~Node_T ();

      void addNewAttribute(Attrib_Base_T* p);

      Attrib_Base_T* getAttribute (size_t i);

    private:

      typedef std::vector<Attrib_Base_T*> Attribs_T;

      Attribs_T m_Attribs;
  };

  void Node_T::addNewAttribute(Attrib_Base_T* p)
  {
    m_Attribs.push_back (p->Copy ());
      // If Node owns the instances, it probably wants
      // copies - can't use a copy-constructor due to
      // the run-time type being unknown, so use a virtual
      // "Copy" method.
  }

  Node_T::~Node_T () // If responsible for deleting items
  {
    for (Attribs_T::iterator i = m_Attribs.begin ();
         i != m_Attribs.end (); ++i ) delete (*i);
  }

This isn't a stupid interpretation of "any class" - remember, you can
create of heirarchy of wrapper classes if working with unrelated
classes defined outside your control. The wrappers basically resolve
all the which-kind-of-attribute-am-I-dealing-with issues, ideally by
defining a common interface in the base class for the wrappers.

You might use std::auto_ptr in place of pointers, but beware of the
freaky assignment operator.

If you really mean *any* class, you can store void* pointers, but you
take on some awkward responsibilities and you have more restrictions.
For example, if your node class is responsible for deleting those
instances, you'll need some way of identifying which classes
destructor to call for each instance. Similarly, how do you know which
classes Copy method to call?

If pointers really aren't appropriate, there are ways, but they really
aren't a good idea. The obvious place to look is the union, but you'd
probably want an "unrestricted union" that won't be available until
C++0x.

http://en.wikipedia.org/wiki/C%2B%2B0x#Unrestricted_unions

And what you *really* need may well well be a "variant record", but
C++ doesn't have that construct. There *may* be a suitable boost
library, but I'd be surprised if it's worth the effort given the
current state of C++.

Just possibly, what you want is the "reflection" ability of scripting
languages (along with languages designed for the Java and .NET virtual
machines) to identify any instances class (via a reference) at
run-time. C++ cannot do that - it isn't a scripting language, and
doesn't have the scripting language overheads that allow reflection.
However, it is worth considering that internally, what scripting
languages do is essentially to use a either a heirarchy of wrapper
classes or variant-record like structures for most/all values.