Just further to the other advice:
It is not a good idea to make your member variables public. Make them all private, and then provide an interface of public functions to interact with them. Don't be tempted to provide get / set functions for each one though.
Also, it is normal practice to put the definition of your member functions into their own .cpp file. Include the header file for any .cpp file that needs to use that class. As MikeyBoy
says, it is bad to include .cpp files, the compiler will find all the function definitions as long as you include the header. There is a bit of confusion there - your Functions.h looks as though it should be a Functions.cpp file. I am saying add the constructor, arrCreate and destructor to it as well. Here is an example, using the scope operator:
return pow(vr, -3.0) *
incGamma(a, vr) -
incGamma(a, vci) +
exp( - pow(vco / c, k) ) -
exp( - pow(vr / c, k) );
This brings me to another point: All the functions you have take a reference to a parameters object, which is what makes me think they should be class functions (which is why I said about the Functions.h file) - at least in a simple implementation. If this is so, then you can refer to your member variables directly (I edited your code), and there is then no need to have them public. It just seems messy to have a load of external functions that deal exclusively with member variables.
A more complicated implementation might be like what I described here:
No one has commented one way or the other on this (does that mean it's right?). I wonder if I could indulge MikeyBoy
or anyone else to comment on how this might work for the OP, or reply to my topic?
Also you should have a constructor that takes arguments for all your member variables, have it use an initialiser list like NwN
suggested - but for all the member variables. Then you don't have to initialise them all in main().
With your variable names, don't abbreviate them too much - I would prefer names such as
. This way the code can be self documenting just on the variable & function names. With member variables it is a handy and common to name them with a leading m_.
With comments, you can use them to:
1. Describe what the class is for
2. 2 or 3 lines to describe functions do, or copy & paste in a formula
3. preconditions & postconditions like range of acceptable values
4. Any other reference material like a website URL that might be of benefit
In summary, you want to make the code as clear as possible for anyone who has to read it - including yourself in 2 years time say.
Hope all is well at your end :+)