Le mercredi 16 septembre 2009 à 10:22 +0100, G. Perendia a écrit :
Re Q. 3.b) as an extension to this question I also wrote: "I now expect it is both more in line with the NTK policy and also quicker to pass them [the pointers to Matlab structures] as arguments as we can reduce both, the freedom of access [by the C++] and the number of calls to Matlab respectively."
Thus, I suggested as quicker and passing the structure pointers as arguments (by pointer) instead of using multiple calls to mexGetVariablePtr().
Is that OK then?
If by structure pointers you mean the "mxArray*", then I agree with that.
----- Original Message ----- From: "Sébastien Villemot" sebastien.villemot@ens.fr To: "List for Dynare developers" dev@dynare.org Sent: Wednesday, September 16, 2009 9:43 AM Subject: Re: [DynareDev] C++ DsgeLikelihood and Dynare Parameters
Le mardi 15 septembre 2009 à 15:36 +0100, G. Perendia a écrit :
- For start, I believe that there is a certain (however small)
development,
maintenance and performance overhead in maintaining strict "Need-to-know" data policy all the way through.
Hence, as an optimal solution (as per my response to Michel's email yesterday and I believe in line of what you wrote), I believe that:
a) we should still use the new GeneralParams data tree interface
framework
to manage interface to the pointer(s) to the structure(s) (i.e. one or
more,
see below) LOCAL to the calling Matlab function, and,
b) only the high level functions should "know" the reference to the GeneralParams structure (whose implementation contains pointer(s) to the Dynare structure(s)) and they use it to query only the params needed
locally
and/or to be passed as arguments to the lower level functions they call either in loop or ad-hoc.
I agree with that solution.
- Still outstanding issues for clarification are:
a) should we start imposing the "NTK" policy as high as Matlab Dynare calling function and there create a single new structure containing only
the
params needed by C++ estimate before calling it, or leave to C++ to manage the access on the as need-to-know basis.
The goal is to extend this policy throughout all the code, even the M-files (ideally we should drop the "options_" structure). So try to apply it as high as you can.
b) Again, should we use mexGetVariablePtr() to query structure(s)' pointer(s), or pass the structure(s) as argument(s) - i.e. as pointer(s)
in
either case?
I'm not sure to understand your question correctly, but I think that mexGetVariablePtr() should be called only once at the top-level for getting the mxArray pointer to the structure, and then pass the mxArray pointer to subroutines.
PS: sorry for misnomer: mexGetVariablePtr(), as its name suggests, passes pointer, not C++ type reference - I only referred to "by reference" in a more generic fashion, just as opposed to "by value" (as mexGetVariable() does) and since, as I understand, Matlab can not pass C++ references to
C++
but only pointers.
Of course, in this case, you can escape using a pointer. But in your own code I strongly encourage you to avoid pointers and use references whenever possible.
Best,