Thread overview
Deserializing const fields
Sep 05, 2012
Jacob Carlborg
Sep 05, 2012
Jacob Carlborg
Sep 06, 2012
Jacob Carlborg
Sep 07, 2012
Jacob Carlborg
September 05, 2012
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
September 05, 2012
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
September 05, 2012
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
September 06, 2012
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
September 06, 2012
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
September 07, 2012
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