Hi George,
Le lundi 14 septembre 2009 à 12:11 +0100, G. Perendia a écrit :
I have been working on a fundamental approach to the further below outlined (see enclosed email below) issue of dynare structures, either global or local, being available inside C++ modules and have developed prototypes of two classes that provide for integration of the parameters inside one class and for their access and modification. (The location ands scope of the original Dynare param structure need not be global but can be also local to the calling Dynare matlab modules.)
In your class prototype, you should use a "const string &" rather than a "char *" for the "field" parameter. In C++ code it is much easier to manipulate strings than char*. And passing the argument by reference doesn't involve any performance loss, since it is technically equivalent to passing a pointer.
As a general rule, I agree with Michel that we should generally pass arguments to functions, rather than using global structures to access a big database of all possible options. The main advantage is that of modularity: the function prototype immediately shows us which are the options used in the function, and which are the options which are not. If we use the same big set of options for all functions (such as we currently do with "options_" in the M-file, or such as the design which you have in mind), we create interdependencies between all parts of the code, which is the very opposite of modularity.
So I think that in the design of C++ library, we should break with the philosophy of passing all options to all functions, and only pass what is necessary as arguments. In the case where you need to pass many options at a time, you can create a special structure for storing them, knowing that a passing-by-reference is very efficient in terms of memory and speed.
Best,