seems like a handle class nesting bug

classdef IqReader < handle
properties
fid=0
end
...
end
classdef InReader < handle
properties
reader=IqFileReader()
end
...
end
classdef T1Reader < InReader
...
end
classdef T2Reader < InReader
...
end
t1=T1Reader();
t2=T2Reader();
assert(t1.reader ~= t2.reader);
In the example above (when split into files as matlab requires), t1 and t2 get the same handle class object as a reader. e.g. changing t1.reader.fid changes t2.reader.fid
This does not seem right to me.

2 个评论

cut and paste bug in example: first class should be IqFileReader
Then edit it to correct the first post rather than post the correction as a comment.

请先登录,再进行评论。

回答(1 个)

Not a bug. See the "Handle Objects as Default Property Values" section on this documentation page for an expanation and an alternate approach to give each instance of the class a separate handle object as its property.

2 个评论

The doc is unclear re my example however. It says different instances get the same handle-derived property: ok, but my example did not have different instances of the same class, it had two different derived classes, each with a single instance.
This is not good, and not documented. Call it an undocumented feature rather than a bug possibly.
However, it does seem good practice to initialise handle derived properties in the constructor - the behaviour if you don't is very unlikely to be desired, or expected.

请先登录,再进行评论。

类别

产品

版本

R2022b

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by