unexpected crash when overloading subsasgn
in [Matlab]
|
From: Steven Lord on 28 May 2010 14:03 "Matt J " <mattjacREMOVE(a)THISieee.spam> wrote in message news:htotp9$ea2$1(a)fred.mathworks.com... > "Eric Salemi" <eric.salemi(a)septentrio.com> wrote in message > <htoms0$3ad$1(a)fred.mathworks.com>... >> "Matt J " <mattjacREMOVE(a)THISieee.spam> wrote in message >> <htolme$i5g$1(a)fred.mathworks.com>... >> >> > This could be part of the problem. When you call >> > builtin('subsref',this,index) you are passing a non-builtin MATLAB >> > object (i.e. "this") to a builtin function. Perhaps you should do >> > struct(this) at the top of the file. >> >> I actually think that within an overloaded subsref, any call to subsref >> will call the builtin version of subsref anyway. > ================= > > No, you have to specify that the builtin version should be called. For > example, this line in your code > varargout{i} = subsref(this(i),index); > > is resulting in recursive call to MyClass.subsref, which you can easily > verify by having subsref print a message to the screen each time it is > called. It is not an infinite recursion because the call is contained > within an if...else, which terminates the recursion. Anyway, I did my own > tests, and discovered that builtin subsref is indeed smart enough to strip > "this" down to a struct. It depends on what you mean by "any call". If you _implicitly_ call SUBSREF inside a method of your object, say by performing this(i) where this is your object, the built-in SUBSREF will be called. If you _explicitly_ call SUBSREF inside a method of your object [using subsref(this, ...)] then the overloaded SUBSREF will be called. So Matt, you actually called both SUBSREFs in your example -- the built-in to handle this(i) then the overload due to your explicit subsref() call. This is documented in the Object-Oriented Programming documentation: http://www.mathworks.com/access/helpdesk/help/techdoc/matlab_oop/br09eqz.html#br09nsm I believe this holds both for classdef-based classes and older-style classes. -- Steve Lord slord(a)mathworks.com comp.soft-sys.matlab (CSSM) FAQ: http://matlabwiki.mathworks.com/MATLAB_FAQ To contact Technical Support use the Contact Us link on http://www.mathworks.com
From: Matt J on 28 May 2010 15:07 "Steven Lord" <slord(a)mathworks.com> wrote in message <htp0he$71d$1(a)fred.mathworks.com>... > > It depends on what you mean by "any call". > > If you _implicitly_ call SUBSREF inside a method of your object, say by > performing this(i) where this is your object, the built-in SUBSREF will be > called. > If you _explicitly_ call SUBSREF inside a method of your object [using > subsref(this, ...)] then the overloaded SUBSREF will be called. > > So Matt, you actually called both SUBSREFs in your example -- the built-in > to handle this(i) then the overload due to your explicit subsref() call. ======= That's true, of course. I'm pretty unsophisticated when interpreting the word "any". I assumed here that it means "all the options", in this case calling subsref either explicitly or implicitly.
From: Matt J on 28 May 2010 15:42 "Philip Borghesani" <philip_borghesani(a)mathworks.spam> wrote in message <htosju$2nn$1(a)fred.mathworks.com>... > You are bumping into a limitation of the design of subsasgn. See http://www.mathworks.com/support/bugreports/194179 ===== There seem to be some interesting and undocumented exceptions to this limitation, however. When I add the following subsasgn implementation to the OP's class function this = subsasgn(this,index,varargin) for ii=1:min(length(varargin),length(this)) this(ii)=builtin('subsasgn',this(ii),index,varargin{ii}); end end then I get the correct behavior some of the time. That is, this works fine: >> [obj.field]=deal(1,2); obj.field ans = 1 ans = 2 but this does not >> [obj(:).field]=deal(3,4); obj.field ans = 3 ans = 2
From: Eric Salemi on 28 May 2010 17:38 "Philip Borghesani" <philip_borghesani(a)mathworks.spam> wrote in message <htosju$2nn$1(a)fred.mathworks.com>... > You are bumping into a limitation of the design of subsasgn. See http://www.mathworks.com/support/bugreports/194179 Hi Philip, Thanks for the pointer. I think it answers my question. The bug talks about dot and cell referencing on non-scalar user-defined object. As far as I am concerned dot-assignment of the type [obj.field] = deal(true) is working on my classes with R14. However performing deep nested dot-assignment like [obj.field(:)] = deal(true) does crash. cell-assignments always crash (deep or not). I can perform dot and cell reference (deep or not). I'm happy to see that Mathworks already fixed a large part of the issues described in the bug. This is good news. Second you confirmed that the crash I experience are now replaced with clean errors in more recent versions, which is good to know. Let's hope that Mathworks can think of a clever way to allow full dot and cell operator support for OOP. Regards, Eric.
From: Eric Salemi on 28 May 2010 17:52 "Matt J " <mattjacREMOVE(a)THISieee.spam> wrote in message <htp49a$49r$1(a)fred.mathworks.com>... > "Steven Lord" <slord(a)mathworks.com> wrote in message <htp0he$71d$1(a)fred.mathworks.com>... > > > > > It depends on what you mean by "any call". > > > > If you _implicitly_ call SUBSREF inside a method of your object, say by > > performing this(i) where this is your object, the built-in SUBSREF will be > > called. > > If you _explicitly_ call SUBSREF inside a method of your object [using > > subsref(this, ...)] then the overloaded SUBSREF will be called. > > > > So Matt, you actually called both SUBSREFs in your example -- the built-in > > to handle this(i) then the overload due to your explicit subsref() call. > ======= > > That's true, of course. I'm pretty unsophisticated when interpreting the word "any". I assumed here that it means "all the options", in this case calling subsref either explicitly or implicitly. Matt, You did interpret my "any call" correctly :) Steven, Thanks for the clarification, what I said was obviously wrong.
First
|
Prev
|
Pages: 1 2 3 Prev: IR-Spectra Next: www.voguesneakers.com Cheap Jordans,Cheap Nike Shox R4,Cheap Air Max 90 |