[geeks] reigning in the growing object class

[Joshua D Boyd]

So, I previously got chewed out for using void* in c++, and so I avoided
it, because it was the write thing to do.  But, now I'm at the point
were I want to be able to build a list of attributes, where each
attribute is a pair that is a name and a value, and the values need to
be strings, floats, or other classes.  So, I've been building a value
class that looks something like:

class Value {
  string  strVal;
  float   fVal;
  Pt4     pt4Val; // A class that represents vector with various
                  // conversions and common operations in it.
  Object* objVal;
  enum ValType {STRING, FLOAT, PT4, OBJECT};
  ValType type;
}

But, I keep wanting additional types of values, like Pt3s, or Group*s,
or vector<float>s, etc, and so I find myself continually changing Value,
and every change means more memory wasted, and I just long to do:

class Value {
  enum ValType {STRING, FLOAT, PT4, OBJECT};
  ValType type;
  unsigned int size;
  void * val;

  float getFloat() {
    ASSERT(type==FLOAT);
    return (float)*val;
  }
  //... etc, for the other types.
}

where size says how large structute val points at, and to add additional
types, I just add them to the end of the enum, and all existing code
ignores values that they weren't made to understand.

Something else I've played with is making value a

class Value {
  string type;
  string val;
  
  float getFloat() {
    ASSERT(type=="float");
    return atof(val.c_str());
  }
  Pt4 getPt4() {
    vector<float> temp;
    ASSERT(type=="Pt4");
    temp.resize(4);
    //...
    //code to parse val into sub strings, and convert substrings 
    //to floats in temp
    //...
    return Pt4(temp[0], ...);
  }
}

and then all possible things that might be passed by value have to
figure out how to serialize themselves.  I might do that, but I'm not
thrilled about having to take the time write this.  Other than a small
number of point classes (points get passed around so much and are so
small I wanted to make sure that the points were abused by sloppy
programmers, like myself somedays, forgetting to delete things, etc) and
one matrix class, pretty much all my classes are derived from a commond
object, so if I could just make a generic way for it to serialize
itself...  Well, I'm just not that thrilled about it at the moment, but
really, how often would I need anything other than strings, floats, and
points?  I don't think much for this code.

Of course, one would think that the easy solution would be to use a
dynamically typed language instead of C++, but I don't get the luxory of
saying "This language will work, but we need the time to develop
extensions to it to interface with windowing system of choice.", and
instead have to go with what is "known" to work, even if the complexity
is prohibitive.  There is also a strong C++ bias.  When they evaluated
one product, which did in fact have some rather annoying "features", the
biggest complaint was they wanted to program in a "real" language, not
python, and where were they supposed to find students who knew python to
work on the project if they went with it, and what was with the silly
joining pipes between objects and classes (system in question was
derived from VRML2.0, with extensive additions plus a C++ API for easily
making ones own further additions, and python substituted for
javascript). 

I'm just really frustrated at this whole C++ thing which I'm loosing
major sleep over, but it is either add dynamic type style stuff, or else
continue to bloat my low level classes to add anything that a higher
class might want to have called.  Like, say, being able to set options
about how an object is rendered, when not all objects have the same
options.  Like, having a draw normal option doesn't make sense when the
object is an image overlay, so forcing all objects to have a draw normal
overlay option would make writing my image overlays more difficult.

I should have taken this class sooner.  All the difficulty in it is
making me really panic about the my future.  How am I supposed to work
effectively for a challenging employer if I have so much trouble with
these "basic" issues.

-- 
Joshua D. Boyd