Thread: Passing many dozens of arguments to a function in C++

The C++ functions that I have been designing often receive many dozens of arguments that are control parameters with complicated data structures, and this is in addition to the data that will be processed by these functions.

So I will appreciate some philosophical advice about the sort of organizational strategy experienced C++ programmers would use in such contexts.

Since the numerical data is often larger than many gigabytes, destined to approach hundreds of gigabytes in size, I have already been storing all data in binary files in the hard disk, and one of the "arguments" that the function receives is the name of the data file. The functions efficiently read the basic numerical data from the hard drive accordingly, but separately, there are still many dozens of control parameters that must be passed to the function as arguments. Even declaring these parameters as global variables to reduce the number of arguments that the functions receive, is beginning to cause unexpected difficulties, because in order to make this work, I still need to create many data structures to store the parameters in such a way that each function will know which parameters to use ( vectors of vectors of many different types (the types being various structs, etc, like vector < vector <Type1> > , where Type1 is a struct which might have to contain vectors also.)

Right now, one remedy I am about to try is to stop trying to make the main program read and organize the control parameters from the disk file that stores the control parameters, and instead, to let each function read its own control parameters from the original text file buried in the hard disk. This would make the data structures of the control parameters a lot simpler, since each function will only have to read its own parameters, so that instead of the main program having to construct a vector of vectors like vector < vector<Type1> > , each function will internally need to use a only one dimensional vector of the form vector<Type1> (even if Type1 is in fact a structure that might contain a vector of Type2 among other things, this is still a lot simpler to initialize, fill and access, since the complexity of having to store simultaneously all the control parameters of all functions is eliminated.) This is because there are many functions which get organized in a vector of functions or a map of functions, and this method of making each function read its control parameters directly from the disk file will make the complexity of the data structures simpler. In fact, maybe for parallel programming to let all functions work independently, this trick of letting them read their control parameters from a disk file might also work.

Any suggestions will be appreciated. Basically, the situation is more complicated than passing dozens of arguments of the same type or simple types.

Code:

struct ControlParameters
{
     // your dozens of control parameters here
};

void YourFunction(const std::string &filename,  ControlParameters &parameters)
{
    // do whatever is needed, in nice, small, well-defined pieces, including separate supporting functions.
}

If the function does not need to modify and return the control parameters, the second argument can be const.

Your parameters most likely can be placed into some kind of hierarchical representation. That is, some of them are probably related to each other, and some of them could be seen as "children" of other parameters. Realize these relationships in code. Match the domain, instead of flattening it into a mind-numbing list of numbers.

of all the published software that has been written - obviously many of it with massive complexity - how much of it do you imagine was / is finally implemented with functions that require(d) dozens of arguments? That must tell you something.

Any suggestions will be appreciated. Basically, the situation is more complicated than passing dozens of arguments of the same type or simple types.

I agree with whiteflags - Just what exactly is the 'situation' ? If you describe the program goal - tell us what your application is supposed to do and offer some relevant code you will allow people to better understand and offer more accurate advice.

Originally Posted by whiteflags

That is very odd. Why so many? Functions are always supposed to do something; they are not countless points of data that you need to structure and refine information from.

I would like to know what you are really doing as opposed to what your broken idea is.

Basically, deciding to build many dozens of functions is just my primitive way of making sure that no function will have more than 1,000 lines of code, or else I won't be able to debug it in general: In fact, the average function has only 500 lines. Each function makes calculations, sometimes solves various differential and integral equations by approximate means, and tries to find patterns in the data by these means. By decentralizing and then comparing the results of many alternative calculation methods, one can build the entire project step by step, with only small setbacks along the way.

Anyway, a central theme in all these functions, is to make calculations in many sub-ranges of data, and in many scales. For instance, although the functions use significantly different methods of calculating, each function uses at least the following control parameters that are initially written in a text file (the text file is either manually modified or it gets modified by means of a GUI interface):

Code:

1) // The binary random access file name and the key file name that provides the information about 
    // how the data was partitioned.

2) // TestTime; // a time location t=T_0 within the available range of time in data

3)  //Each function needs the time scale information as follows:
    vector<IntervalInfo> vec_Intervals; 
    // where IntervalInfo is of the form:
     // struct IntervalInfo {
        // int WidthOfInterval; // in discrete time units
        // int LocationOfInterval; // distance of the interval's (right or left) from origin
       //  vector<int> vec_DegreeOfPolynomial;
    }; 
    // Thus each of the time intervals (which may be nested or overlapping 
    // or disjoint), will have several polynomials of chosen degrees that will be 
    // applied to the data to extract a pattern in that interval.
     // (Usually least square polynomials.)

4)     vector<ReferenceTrajectory> vec_ReferenceTrajectories;
        //where ReferenceTrajectory is of the form:
         // vector<double> ReferenceTrajectory;
        // and a ReferenceTrajectory is just a time-dependent curve in time in 
        //the  data file, which is pre-determined either from experiment or theory.

So far, these 4 kinds of control parameters above, are for each function, but since often each function will use different a different configuration of control parameters, this means that a different argument will be passed to each function, even though the format of the arguments is similar. This means that since the dozens of functions were already organized in a map of functions (to make it possible to iterate over these functions), it follows that I will have to prepare the above 4 arguments just before the function call.

Otherwise, if I read and prepare all the control parameters ahead of time before the dozens of functions are called in iteration, then I would have to build an even bigger vector which contains elements that are made of structs that contain the above 4 kinds of control parameters in a different configuration for each function.

Of course, right now, in order to make the code more robust and decentralized, I am about to abandon preparing the types 3) and 4) arguments for the functions: instead I am going to let each function read its own parameters from the disk file independently. This will avoid trouble, and it will also avoid using global variables.

But as you can see, even if I prepare the control parameter arguments separately for each function, I already have do construct and then decipher two-dimensional vectors already, and this is somewhat tricky.

In any case, I must admit that the C++ book of Alex Allain has been extremely helpful: this book is full of very practical examples that are chosen in such a way that I often instantly find a way of using more advanced C++ methods to organize calculations I was unable to do before. I bought the latter book a few months ago and it dramatically improved my programming. (Even though I have accumulated two dozen C++ books during the last two decades, I have never used these in any serious way, always programming with for loops in general.)

Originally Posted by FortranLevelC++

Basically, deciding to build many dozens of functions is just my primitive way of making sure that no function will have more than 1,000 lines of code, or else I won't be able to debug it in general: In fact, the average function has only 500 lines.

Holy crap. Granted, one of the two languages I primarily use is C# which in general is somewhat more terse than C++, but I aim to keep things below about 20 lines of code and a very long method would be around 100 LOC.

Why do you need to read methods from a file? The whole idea smells a bit of the inner-platform effect, which is a common antipattern in software development. If you actually need to iterate over a lot of methods, I'd set this up as functors (aka function objects) all which derive from an ABC and organize your classes logically into namespaces, while refactoring any shared tasks into separate functions, perhaps in a base class. You can iterate over a vector of functors rather than iterating over a list of strings from a disk file.

Also if you're doing a lot of complex math, you might simply try something more suited to that, like Maple, Mathematica, or Matlab. If you need to do a front-end and don't want to do it in their languages, all of the above I believe have DLLs you can use with C or C++.

Basically, deciding to build many dozens of functions is just my primitive way of making sure that no function will have more than 1,000 lines of code, or else I won't be able to debug it in general

I have never heard so much bollocks in my life - from what programming planet did you come.

By decentralizing and then comparing the results of many alternative calculation methods, one can build the entire project step by step, with only small setbacks along the way

yet more waffle

In fact, the average function has only 500 lines.

Oh thats ok then, i take it all back, haha, good grief, spit it out man - what are you trying to make?

Originally Posted by grumpy

Code:

struct ControlParameters
{
     // your dozens of control parameters here
};

void YourFunction(const std::string &filename,  ControlParameters ¶meters)
{
    // do whatever is needed, in nice, small, well-defined pieces, including separate supporting functions.
}

If the function does not need to modify and return the control parameters, the second argument can be const.

This is going half way to where it needs to. It's probably better to do this (depending on the details of what the OP is trying to do):

Code:

struct NameForWhatFunctionDoes{
     // your dozens of control parameters here
    void NameForWhatFunctionDoes::YourFunction(const std::string &filename);
};

void NameForWhatFunctionDoes::YourFunction(const std::string &filename)
{
    // function body
}