MATLAB Answers


Can MATLAB pass by reference?

Asked by Doug Hull on 18 Jan 2011
Latest activity Commented on by James Tursa
on 14 Sep 2018
How does MATLAB deal with this?

  1 Comment

Check out: "How MATLAB Allocates Memory" in the Matlab help files

Sign in to comment.

4 Answers

Answer by Doug Hull on 18 Jan 2011
 Accepted Answer

If you are attempting to use pass-by-reference to modify the input argument passed into a function, the answer to the question depends on whether the input is a handle object or a value object. The two types of objects are described in the Object-Oriented Programming and Programming Fundamentals sections of the documentation. By default, objects (including matrices, arrays, etc. of the built-in data types) are value objects.
Handle objects do exhibit reference behavior when passed as function arguments; value objects do not. When you pass a handle object to a function, MATLAB still copies the value of the argument to the parameter variable in the function (with one bit of subtlety; see below.) However, all copies of a handle object refer to the same underlying object.
If a function modifies a handle object passed as an input argument, the modification affects the object referenced by both the original and copied handles. In this case, the function does not need to return the result to be reassigned.
If instead you are attempting to use pass-by-reference to avoid unnecessary copying of data into the workspace of the function you're calling, you should be aware that MATLAB uses a system commonly called "copy-on-write" to avoid making a copy of the input argument inside the function workspace until or unless you modify the input argument. If you do not modify the input argument, MATLAB will avoid making a copy. For instance, in this code:
function y = functionOfLargeMatrix(x)
y = x(1);
MATLAB will not make a copy of the input in the workspace of functionOfLargeMatrix, as x is not being changed in that function. If on the other hand, you called this function:
function y = functionOfLargeMatrix2(x)
x(2) = 2;
y = x(1);
then x is being modified inside the workspace of functionOfLargeMatrix2, and so a copy must be made.
For more information on this behavior, read this posting on Loren Shure's blog.
[From the MATLAB FAQ of Ancient Times]


Show 1 older comment
You need to pay special attention to where you are making the call from. If you make this call not from within a function (e.g. the command line), then a temporary deep data copy WILL be created. If you make this call from within a function, then the deep data copy WILL NOT be created. E.g., from the command line (prpi is a simple mex function that displays the variable and data addresses):
Using this file:
% File myfunc.m
function var = myfunc (var)
var(1) = 1;
From the command line:
>> x = zeros (10000, 10000);
>> prpi(x)
mxArray address = 07C85DB0
pr = 26EF0030
>> x = myfunc(x);
mxArray address = 07C87438
pr = 7FFF0030
>> prpi(x)
mxArray address = 07C85DB0
pr = 7FFF0030
So you can see that a deep data copy was made from within myfunc.m since the pr address is different. But now do the call from within this function file:
% File myfunc_test.m
function myfunc_test
x = zeros (10000, 10000);
x = myfunc(x);
Running this function:
>> myfunc_test
mxArray address = 07C86E50
pr = 26EF0030
mxArray address = 07C87978
pr = 26EF0030
mxArray address = 07C86E50
pr = 26EF0030
The pr address is the same throughout, indicating that a deep data copy was not made from within myfunc( ).
Thanks for the thorough answers to my comment!

Sign in to comment.

Answer by Marco
on 18 Jul 2012

Is this also true for nested function calls? Cuz it seems like it only works for direct function calls. In my GUIDE gui I have a function (call it Fn_takesHandles) that takes in the figure handles and updates the axes, when called by callback functions directly works just as intended. However, I run into problems when the stack frame is not one-to-one. A callBack function calls a helper function called Auto which in turn calls Fn_takesHandles. In this case it does not work as intended. Any changes made to the figure handles by Fn_takesHandles is not persistent. How would you go about solving this problem?
Is there any way to declare pointers in matlab? Any help would be appreciated!!

  1 Comment

There is no way to declare pointers in MATLAB (at least not for calling MATLAB functions; there are ways to copy around pointers that have been created at the C / C++ level.)

Sign in to comment.

Answer by Jason Climer on 20 Jun 2017

Is this determined during the JIT compilation or as needed, i.e., is the copy of x made upon the function call or when the program executes
x(2) = 2;

  1 Comment

It is generally determined when the program executes, as it is not always possible to tell ahead of time whether a value is shared or not. Especially when you consider the hidden effect of assignin() .
Also, overloading can happen at run-time: the current directory or path of an operation at the time a routine is first JIT'd is not necessarily going to be the same as during a later operation.
There are cases where MATLAB does enough analysis to establish that "update in place" can happen; I do not know enough about the mechanics of that to say how it is done taking into account overloading.

Sign in to comment.

Answer by Mandeguz on 22 Jun 2017

How about when writing MEXs? Can one pass by reference within the computational routine and pull those values back to the main MATLAB code that called the MEX?


on 22 Jun 2017
All variables are provided by reference in a Mex function: you get only pointers to the inputs. The documented MEX functions do not allow to modify the inputs directly, but it is required to create a data copy at first. But of course in the C level there is a way to maniipulate the (potentially shared data) directly. There are several undocumented methods to handle shared data copies, see e.g. . Search for "mxCreateReference" and "mxCreateSharedDataCopy" in the net to find more details.
Also, keep in mind that struct and cell array references are evaluated as shared data copies at the caller level before the argument is passed on to the mex routine. E.g.,
x = something;
mymex(x); <-- The address of x is passed into the mex routine
y.a = something;
mymex(y.a); <-- The address of a temporary shared data copy of y.a is passed into the mex routine
z{1} = something;
mymex(z{1}); <-- The address of a temporary shared data copy of z{1} is passed into the mex routine
If the struct or cell element hasn't been created yet (i.e., is actually NULL), then a temporary empty double variable is created on the fly and the address of that is passed in.
So, when working with struct and cell arrays, it is more efficient to pass them in as whole variables and extract the element pointers inside the mex routine to avoid those temporary shared data copies.
Also note that as of R2015b, MATLAB passes arguments to mex routines as shared data copies (it used to pass them by reference).

Sign in to comment.