• Jacob Carlborg (14/14) Sep 05 2012 I hit an interesting problem in my serialization library: deserializing
• Andrei Alexandrescu (6/18) Sep 05 2012 Deserialization is a low-level operation, and it shouldn't invoke a
• Jacob Carlborg (4/8) Sep 05 2012 Hmm, I'll give that a try.
• Jacob Carlborg (10/14) Sep 06 2012 I gave this a try but I have two questions:
• Andrei Alexandrescu (7/21) Sep 06 2012 Except for pointers, which of course need to be handled carefully
• Jacob Carlborg (4/8) Sep 06 2012 Thanks.

Jacob Carlborg <doob me.com> writes:

I hit an interesting problem in my serialization library: deserializing 
const (and immutable) fields. The problem is that const fields need to 
be set in a constructor.

In my current implementation I don't call the constructor at all. The 
reason for this is that I want to be able to (de)serialize classes 
without a default constructor. Instead it's possible to register event 
handlers for when a class is deserialized.

So I think that I either need to require that a class with const fields 
need to have a default constructor or a constructor that takes the 
serializer as an argument and leave the class to manually deserialize 
the const fields in the constructor.

Anyone got any other ideas?

-- 
/Jacob Carlborg

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 9/5/12 9:08 AM, Jacob Carlborg wrote:
 I hit an interesting problem in my serialization library: deserializing
 const (and immutable) fields. The problem is that const fields need to
 be set in a constructor.

 In my current implementation I don't call the constructor at all. The
 reason for this is that I want to be able to (de)serialize classes
 without a default constructor. Instead it's possible to register event
 handlers for when a class is deserialized.

 So I think that I either need to require that a class with const fields
 need to have a default constructor or a constructor that takes the
 serializer as an argument and leave the class to manually deserialize
 the const fields in the constructor.

 Anyone got any other ideas?

Deserialization is a low-level operation, and it shouldn't invoke a 
constructor because the object has been constructed at serialization time.

I suggest you allocate a chunk of raw memory, deserialize into it, then 
cast it to the object type.


Andrei

Jacob Carlborg <doob me.com> writes:

On 2012-09-05 09:18, Andrei Alexandrescu wrote:

 Deserialization is a low-level operation, and it shouldn't invoke a
 constructor because the object has been constructed at serialization time.

 I suggest you allocate a chunk of raw memory, deserialize into it, then
 cast it to the object type.

Hmm, I'll give that a try.

-- 
/Jacob Carlborg

Jacob Carlborg <doob me.com> writes:

On 2012-09-05 09:18, Andrei Alexandrescu wrote:

 Deserialization is a low-level operation, and it shouldn't invoke a
 constructor because the object has been constructed at serialization time.

 I suggest you allocate a chunk of raw memory, deserialize into it, then
 cast it to the object type.

I gave this a try but I have two questions:

1. Is that safe to do with immutable fields?

2. If I'm allocating a chunk of raw memory then I would need to recreate 
the vtable, classinfo and other stuff. Would it be safe to just create a 
new instance with the "_d_newclass"? This is the function used by the 
runtime when "new" is used. This will allocate the necessary memory, 
handle all the extra stuff but it won't call the constructor.

-- 
/Jacob Carlborg

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 9/6/12 8:40 PM, Jacob Carlborg wrote:
 On 2012-09-05 09:18, Andrei Alexandrescu wrote:

 Deserialization is a low-level operation, and it shouldn't invoke a
 constructor because the object has been constructed at serialization
 time.

 I suggest you allocate a chunk of raw memory, deserialize into it, then
 cast it to the object type.

 I gave this a try but I have two questions:

 1. Is that safe to do with immutable fields?

Except for pointers, which of course need to be handled carefully 
whether immutable or not, it's fine to deserialize into immutable fields 
as long as you clarify to the compiler you're dealing with ubyte[] and 
cast to the object type after.

 2. If I'm allocating a chunk of raw memory then I would need to recreate
 the vtable, classinfo and other stuff. Would it be safe to just create a
 new instance with the "_d_newclass"? This is the function used by the
 runtime when "new" is used. This will allocate the necessary memory,
 handle all the extra stuff but it won't call the constructor.

Yes, that's the ticket.


Andrei

Jacob Carlborg <doob me.com> writes:

On 2012-09-06 21:54, Andrei Alexandrescu wrote:

 Except for pointers, which of course need to be handled carefully
 whether immutable or not, it's fine to deserialize into immutable fields
 as long as you clarify to the compiler you're dealing with ubyte[] and
 cast to the object type after.

Thanks.

-- 
/Jacob Carlborg