Thanks for your fast reply @Yair.

I’m really just trying to copy an object inside my workspace. There is no file IO involved…

@Mario – I suspect that you are trying to move data between different computer types and/or different Matlab releases, and this is apparently not supported.

from time to time I get the following error:

"Error using getArrayFromByteStream
Unable to read data stream because the data contains a bad version or endian-key"

It seems not to be reproducable.
Do you know reasons or fixes for that?

Best regards,
Mario

@Scott – nice idea!
Thanks for sharing

Hi Bill – You might try creating a simple wrapper class to hold your old object. It’s a little hacky but seemed to work for me.

classdef wrapper
   properties
      oldobj
   end
end

Then use the property to store your old object:

a = wrapper;
a.oldobj = oldobject;
b = getByteStreamFromArray(a);
c = getArrayFromByteStream(b);
c.oldobj

@Balint – You could perhaps create a new user class that inherits from container.Map. However, container.Map also has poor performance compared to java.util.Hashtable (for example). So my advise is to implement your own user class based on an underlying Java object, using serialization/deserialization (as shown in the article above) as needed to store the Matlab objects in the Java object.

So far it appears that both this approach, and the matlab.mixin.Copyable facility requires an explicit call to the copy() method to actually do something. copy() is not called for an A = B call if A inherits from it. Thus to name Copyable as a copy constructor equivalent is a bit of a joke I think, as the copy constructor’s most important feature is that it gets called automatically whenever a new object is created from another object.

Am I missing something here? If not, do you have an idea how could I make containers.Map to follow value semantics, apart from reimplementing it completely in a custom variant?

@Martin –

    “the relationship between load/getArrayFromByteStream and save/getByteStreamFromArray is a bit more complicated than just one using the other. But they both rely on some common internal infrastructure.”

I assume you mean they all use mxSerialize/mxDeserialize under the hood. That would be pretty close…

@Yair – To my knowledge, the relationship between load/getArrayFromByteStream and save/getByteStreamFromArray is a bit more complicated than just one using the other. But they both rely on some common internal infrastructure.

The best way to see the similarity is to compare the bytes coming out of getByteStreamFromArray(data) and save(filename, ‘data’, ‘-v6’). The latter has a header that the former doesn’t have, but this is not the only difference …

The old-style non-classdef classes I’m using do have default constructors. For example the simple test class below give the same error:

@foo/foo.m

function [obj] = foo(varargin)
obj = class(struct('x',1), 'foo');

>> getArrayFromByteStream(getByteStreamFromArray(foo))
Temporary object of class :all: is missing a constructor or an error occurred
in calling constructor with no inputs.