An alternative to a static member object (or: how to make the perfect code?)

[miturian]

So, this is probably a bit abstract, and I apologize if the title was imprecise:

I have a simulation class, which contains a vector of objects of class A, the member functions of which depend on parameters a,b,c:

class SIMULATION
{
vector<A> array;
};

class A
{
A(a,b,c);
}

Within each SIMULATION, a, b and c are constant. Therefore it seems to be a bad idea to give each A its own copies of a, b, c - I only need one for each SIMULATION.
What I do right now is make a, b, c static members of A. That takes care of the memory "problem". However, making the variables belong to A is a bit of an issue, since if my code contains multiple SIMULATIONs, one will indirectly change the parameters in another. That seems a recipe for confounding errors. Then I have considered making a, b, c members of SIMULATION. This is safe, and makes sense. However, as I see it, that would require A to dereference a pointer each time it needs to do something (to access the variables). That is not quite satisfactory either, since speed is really important in this problem (I will be using a, b, c hundreds of millions of times each).

do you have any suggestions as to how I might make A access values of a, b, c (for speed) and still have good separation of the different SIMULATIONs?

Should I expect a speed-increase if I changed a, b, c from static to "local"? (in which case I might ignore the ugliness of having 10 000 identical values). it is my impression that keeping stuff that is used together close together in memory is a good trick.

wise comments, or really good jokes, will be appreciated =)

[Narue]

Actually, I'm curious if you've profiled having a, b, and c as non-static members of SIMULATION and verified that it's too slow for your needs. Writing off a viable option because you think it's not performant isn't the way to go about design.

[miturian]

Before I do that, would it be possible for me to make that test on a simpler example, for instance something like my SIMULATION and A example from above, or does it depend on the surrounding environment in weird and unpredictable ways? I know eventually I will have to make "before" and "after" profiles, but I was thinking I would rather go through the trouble with the most likely candidate. Changing all the constructors and headers is going to be messy business.

thanks

[Narue]

>or does it depend on the surrounding environment in weird and unpredictable ways?
It does to a certain extent, but for the most part the conclusions from your simple test will hold in the real application.

[miturian]

thanks, I'll be reporting the results of that =)

[mike_2000_17]

There are several options for this problem (which is quite usual in numerical simulation code.. where to put the simulation parameters?). I could suggest two that seem to stick out for me:

1) Make a POD-style class (e.g. C-struct) that has all the parameters:

struct SimulationSettings {
  a, b, c;
};

Then have the class A take a const reference to a SimulationSettings structure and hold this reference as a data member. This way, you can associate all the instances of A to a single set of SimulationSettings. To speed things up a bit, try to reduce the use of the simulation parameters or make a more local copy of it (increase memory usage to reduce time taken at dereferencing). In my own experience, I don't think you will have to worry about this too much at the computational level (do the profiling, as suggested). The nice feature of this solution is that you are not directly tying the implementation of class A to the implementation of class SIMULATION (as you would if you had a pointer or reference to SIMULATION in the class A).

2) It might not be appropriate for all settings and stuff, but have you considered using template parameters? For example:

template <double a, double b, double c>
class A {
  A();
};

template <double a, double b, double c>
class SIMULATION {
  vector< A<a,b,c> > array;
};

This way, you have ZERO run-time overhead (memory or time). The drawback is that you get different "incompatible" types of A and you cannot load or change the parameters at run-time. But if you have some parameters that do not need to change at run-time, you can benefit from the zero-overhead. Depending on your implementation of A, it is also possible to allow the parameters to change between a set of fixed values at run-time.