Getting rid of globals #215

Open
kostrzewa opened this Issue Jan 18, 2013 · 3 comments

Comments

Projects
None yet
3 participants
Owner

kostrzewa commented Jan 18, 2013

This is independent of whether or not to use global variables. The point is that we'd like to reduce their usage. We should find a smarter mechanism, also for other solver related global variables (there not so many left, actually)

We could use variable argument lists (...) or alternatively (and better in my opinion), all the functions which should have common interfaces but could require more or fewer parameters depending on the [solver,monomial,..] type can have a void pointer argument which can be passed NULL if not necessary or cast into a struct pointer.

An an example of my general idea, take our "derivativefunction" dummy function pointer, for instance. Most of the actual derivative functions rely on reading a few or even many global parameters, something which we should do away with in the future. By adding structs with the relevant parameters to the monomials we can construct the parameters at launch and then pass a pointer to this when the functions is called.

For example:

struct monomial {
 [...]
  void (*derivativefunction) (void const * const params);
  void (*hbfunction) (void const * const params);

  void * monomial_params;
 [...]
}

gauge_derivative(void const * const params) {
  gauge_monomial_params const * const pars = (gauge_derivative_params const * const) params;
  double beta = pars->beta;
  hamiltionian_field* hf = pars->hf;
  [...]
}

update_momenta(..){
  [...]
    mnl[i]->derivativefunction(const mnl[i]->monomial_params);
 }

Where gauge_monomial_params would be typedef'ed in gauge_monomial.h, malloc'ed and filled with the correct values and then assigned to the params pointer (with a void cast) in init_monomials and later freed in free_monomials (with the correct cast). This would also remove most of the parameters from the monomial struct, leaving only the ones which are truly common to all monomials.

The drawback is that it clearly makes the code much more opaque to read...

Contributor

urbach commented Jan 18, 2013

I think we should go that way, maybe you have seen that I testwise started this with the cg_mms_tm_nd solver...

Contributor

deuzeman commented Jan 18, 2013

Rather than a pointer to void, circumventing all type checking, I'd be in favor of packaging things in parameter structures. Not coincidentally, something like what I tried doing for the smearing architecture. Mainly a matter of cosmetics, though.

Owner

kostrzewa commented Jan 18, 2013

I agree of course in principle but I thought it would be nice to have only one pointer in the monomial struct in addition to all common parameters (rather than many different members, one for each type of monomial). The underlying implementations - gauge_monomial, det_monomial etc. - then define a struct which is particular to their type. This is similar to what GObject does to implement a kind of object orientation in C, but without their introspection and run-time type-checking.

The other reason is that I wanted to avoid having structs which contain unrelated information such as a solver type or maximum number of iterations for the gauge monomial...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment