Hi Sebastien
Thanks,
1) C++ mexGetVariablePtr() can access either pointers to global structure (with option global), or pointer to the structure local to the calling Matlab function (with option local) which would be the same as what would be passed to the called C++ function as argument.
If C++ code changes and needs additional parameter, then it only need to call different param from the interface.
However, if we used a specially created structure of all needed params, it would need to be changed too.
2) Other advantage of the mexGetVariablePtr() based interface is that it allows for easy update of the structures (needed by estimate), including real-time, interactive updates if any future parallelisation requires that real time facility.
3) I will however start working on altering the code as you suggested and create one structure to pass it from Matlab, i.e. create it before calling C++.
Is it ok if I still use mexGetVariablePtr() to pass it by reference or shall I pass it as argument (also by reference) anyway? An alternative is to use mexGetVariable() which copies the structures locally.
I would still retain the interface abstract class and part of its current implementation and just re-implement it to use the single structure passed as argument - I expect we do not want to clutter the estimation C++ code with too many Matlab dependent mex functions.
Best regards
George ----- Original Message ----- From: "Sébastien Villemot" sebastien.villemot@ens.fr To: "List for Dynare developers" dev@dynare.org Sent: Tuesday, September 15, 2009 9:58 AM Subject: Re: [DynareDev] C++ DsgeLikelihood and Dynare Parameters
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,