Proper use of static variables?

[BCC]

Hi,

I have a class with several member variables that should be initialized
according to user input before an object is instantiated. Using a static
variable is required here.

But, I would like to have each object of my class have unique values of
these variables, because the values may be different depending on some other
factor in the object. Something like this:

class CFoo {
CFoo(MyType t);
static double m_x;
static double m_y;

MyType m_type;
};

double CFoo m_x = 0;
double CFoo m_y = 0;

CFoo::CFoo(MyType t)
{
if ( t == TypeX ) {
m_x = 5;
}
else if ( t == TypeY ) {
m_y = 9;
}
}

To do this properly so that each object has properly set m_x and m_y, do I
need to use additional variables as statics?

Or is there a better way?

Thanks,
Bryan

 

[David White]

Hi,

I have a class with several member variables that should be initialized
according to user input before an object is instantiated. Using a static
variable is required here.
Why?

But, I would like to have each object of my class have unique values of
these variables, because the values may be different depending on some other
factor in the object. Something like this:

class CFoo {
CFoo(MyType t);
static double m_x;
static double m_y;

MyType m_type;
};

double CFoo m_x = 0;
double CFoo m_y = 0;

CFoo::CFoo(MyType t)
{
if ( t == TypeX ) {
m_x = 5;
}
else if ( t == TypeY ) {
m_y = 9;
}

What is the point of assigning static members in a constructor, and why are
you not initializing the m_type member?

}

To do this properly so that each object has properly set m_x and m_y, do I
need to use additional variables as statics?

Or is there a better way?

I really can't figure out what you are aiming to do with all this. I don't
understand why you think you need any static variables at all. You usually
pass whatever parameter values are needed to a class's constructor for the
particular instance you are creating. Why can't you figure out what those
values are, and then pass them to the constructor? Unless you have a very
special situation requiring each instance's properties to depend on the
properties of previous instances, I see no need for static members.

I just want to make sure: Are you are aware that the class itself and all
its instances (i.e., objects) have to share a single instance of each static
member? They don't each get their own.

DW

 

[Aaron Anodide]

Hi,

I have a class with several member variables that should be initialized
according to user input before an object is instantiated. Using a static
variable is required here.

But, I would like to have each object of my class have unique values of
these variables, because the values may be different depending on some other
factor in the object. Something like this:

class CFoo {
CFoo(MyType t);
static double m_x;
static double m_y;

MyType m_type;
};

double CFoo m_x = 0;
double CFoo m_y = 0;

CFoo::CFoo(MyType t)
{
if ( t == TypeX ) {
m_x = 5;
}
else if ( t == TypeY ) {
m_y = 9;
}
}

Hello, I'd say you actually want to use instance variables here. See, a
static variable is really just a global variable scoped by the namespace
(that is, the class). So, it can't have multiple values associated with an
instance of a class.

If each instance of CFoo needs different values of m_x and m_y, based on
MyType, then simply remove the word "static" from your example code above,
and things should work out.

Hope this helps,
Aaron

 

[Josephine Schafer]

Why?

Because only static member variables can be defined before any object of the
class is instantiated.
Static members are independent of object creation.


But I think that the OP needs instance member variables because he claims to
need different values for m_x and m_y for different
objects of the class.

 

[David White]

Because only static member variables can be defined before any object of the
class is instantiated.
Static members are independent of object creation.

To do exactly what the user described, yes. I was really just questioning
the whole idea, but maybe I didn't read that part of the post carefully
enough also.

But I think that the OP needs instance member variables because he claims to
need different values for m_x and m_y for different
objects of the class.

That seems the most likely.

DW

 

[BCC]

Because only static member variables can be defined before any object of the
class is instantiated.
Static members are independent of object creation.

Yep! The final goal is to have a user define certain values, so that all
new objects of a particular type have a particular set of values. Using
static variables won't work properly however since variables cannot be
shared accross objects (unless I use some combination of static and
non-static variables).

As David pointed out, I could simply pass the values to the constructor...
except that I have literally about 100 variables. That would be one ugly
constructor that takes 100 parameters.

But I think that the OP needs instance member variables because he claims to
need different values for m_x and m_y for different
objects of the class.

Exactly. What I ended up doing is having non-statics in the class get
initialized from statics in a function called from the constructor. Seems
to work okay, but with 100 variables it bloats the code.

Thanks!
Bryan

 

[Rolf Magnus]

Yep! The final goal is to have a user define certain values, so that
all
new objects of a particular type have a particular set of values.
Using static variables won't work properly however since variables
cannot be shared accross objects

That's the point of static members. A static member variable exists
exactly once for the class, not one for each instance of it.

(unless I use some combination of static and non-static variables).

So basically, you want something like a default value for your member
variables that the user can change. Then why not just do what you say
here and make non-static member variables and for the default values
static members?

As David pointed out, I could simply pass the values to the
constructor...
except that I have literally about 100 variables. That would be one
ugly constructor that takes 100 parameters.

Hmm. I'd tend to see it as a design flaw if you need a class with 100
member variables.

What I ended up doing is having non-statics in the class get
initialized from statics in a function called from the constructor.
Seems to work okay, but with 100 variables it bloats the code.

That's the reason why I'd see it as a design flaw.

 

[BCC]

I do indeed have 100 variables and each one is unique, but they are related.
So for example, I have groupings like this:
class CContainer {
m_circle_area;
m_circle_position;
m_circle_distance;

m_square_area;
m_square_position;
m_square_distance;
// etc, etc/
};

Each triplet then describes the properties of a particular type of object.

Conceptually, what I need to do is if my object is of type 'circle' it only
accesses the properties related to circle from the container class. Maybe
an analogy would help... Imagine a room where you have a chest of drawers.
Each drawer represents an object type, and contains all variables

related

to
that type. So the 'circle' drawer will have circle area, position, and
distance as well as maybe 'oval' area position and distance.

As a new object comes into the room, it opens the drawer corresponding to
its type and utilizes the variables it finds there. The object then leaves,
and new object comes in and opens its drawer (whether it be the same

type

or
not) and does its thing. This repeats.

So, every room needs a drawer with a full complement of properties for all
objects. Each drawer needs to contain only the properties relating to a
particular object, and properties are grouped according to the type of
object they represent.

At the moment, Im thinking about creating a class for each object just for
properties, and maybe putting all related property sets in an array
according to object type:
circle->circleArray[0].m_type;
circle->circleArray[0].m_area;
circle->circleArray[0].m_position;
etc.

I dont know though. Any thoughts on a good structure to use? Best way to
design this? Anything?

I'm wondering if it is similar to a problem I had initializing
cartesian-graph objects. A graph has a lot of variables - fonts, types of ax
es, maps to convert between scales, types of labels etc. In my case it was
really a whole lot of objects with a common owner working together. I did it
by having a separate class for holding all the properties with which I
wanted to initialize the graph. The problem was complex enough for the
properties class to have its own member functions, which were called by the
graph. I even had a hierarchy of properties classes, to match the hierarchy
of graph classes. Once it was all set up, the properties object was passed
to the graph, which set itself up by creating objects of many other classes
(axis objects, map objects, etc) according to the properties given to it.
Below is one such properties class. Note that this class has public member
variables, because it is more a bag of data than an object with behaviour. I
stress that I am not in the habit of making data members public, or even
protected.

class AxisGraphProperties
{
public:
enum AxisType
{
AXIS_NONE,
AXIS_PLAIN,
AXIS_TICKED,
N_AXIS_TYPES
};

public:
AxisGraphProperties();
virtual ~AxisGraphProperties();
public:
virtual ColorPool *GetColorPool() const = 0;

public:
virtual Vir1DMap *MakeDimensionMap(int nDim) const;
virtual Vir1DMap *MakeTraceDimensionMap(int nDim) const;
virtual AxisTickEngine *MakeAxisTickEngine(int nDim, const Vir1DMap
*pMap1D, AxisTickEngine *pRefTickEngine) const;

public:
AxisGraph *m_pGraph;
AxisType m_nAxisTypes[AxisGraph::N_EDGES];
vector_VirVal m_nAxisPriorityLabelPosns[AxisGraph::N_EDGES];
VirRect m_defaultScaleRect;
LogVal m_maxGraphLogLength;

LOGFONT m_lfGraphName;
LOGFONT m_lfAxisName;
LOGFONT m_lfTickLabel;
LOGFONT m_lfAnnotations;

int m_nAxisMaxLabels[VirPoint::N];
int m_nAxisLabelFieldWidth[VirPoint::N];
};

Even without definitions of most of the types used, you can probably get the
idea.

DW

Yes, this is very similar to what I am trying to do. And what you have
described above is very close to what I was thinking I would do.

Thanks!
Bryan