2011/7/27 Fabian Wiesel <fabian [dot] wiesel [..] ...>:
> Hi,
>
> Currently one cannot serialise objects with a virtual destructor
> al
> May I suggest the following changes:
>
> Move common code (createStream) to a free function in detail namespace.
>
> MQTemplateProtocol: Changed the constraint from !has_virtual_destructor to
> has_trivial_copy_constructor,
> as no virtual destructor isn't sufficient constraint for memcpy.
> According to the boost-documentaton, the type_trait only works for gcc 3.3
> since boost 1.46, but I have boost 1.42.1 and it works.
>
> MQSerializationProtocol: Do not derive MQSerializationProtocol from
> MQTemplateProtocol, as the constraints of the latter have to be more strict
> than the former.
It looks fine to me although I can't assess the effects of this change
on code external to RTT (aka rtt_typelib). I'd feel more confortable
if Sylvain approved this too.
Peter
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
Separating MQTemplateProtocol and MQSerializationProtocol
On 07/27/2011 10:19 PM, Peter Soetens wrote:
> 2011/7/27 Fabian Wiesel<fabian [dot] wiesel [..] ...>:
>> Hi,
>>
>> Currently one cannot serialise objects with a virtual destructor
>> al
>> May I suggest the following changes:
>>
>> Move common code (createStream) to a free function in detail namespace.
>>
>> MQTemplateProtocol: Changed the constraint from !has_virtual_destructor to
>> has_trivial_copy_constructor,
>> as no virtual destructor isn't sufficient constraint for memcpy.
>> According to the boost-documentaton, the type_trait only works for gcc 3.3
>> since boost 1.46, but I have boost 1.42.1 and it works.
>>
>> MQSerializationProtocol: Do not derive MQSerializationProtocol from
>> MQTemplateProtocol, as the constraints of the latter have to be more strict
>> than the former.
> It looks fine to me although I can't assess the effects of this change
> on code external to RTT (aka rtt_typelib). I'd feel more confortable
> if Sylvain approved this too.
The rtt-typelib part would not like that, as typelib can handle
std::vector just fine (which has a non-trivial copy constructor). This
is fine in orogen/rock, as types that typelib cannot handle are rejected
anyway.
Something that would work fine would be to throw an exception in the
generic fillBlob implementation if has_trivial_copy_constructor returns
false instead of using a static assertion
Sylvain
Separating MQTemplateProtocol and MQSerializationProtocol
On 07/28/2011 12:05 PM, Sylvain Joyeux wrote:
> The rtt-typelib part would not like that, as typelib can handle
> std::vector just fine (which has a non-trivial copy constructor). This
> is fine in orogen/rock, as types that typelib cannot handle are rejected
> anyway.
>
> Something that would work fine would be to throw an exception in the
> generic fillBlob implementation if has_trivial_copy_constructor returns
> false instead of using a static assertion
The downside of this approach would be, that user instantiating the
wrong template would get a compile-time error instead of a run-time
error, and even if not, dead-code would be generated.
Another possibility would be, not to derive
orogen_transports::MQTypelibMarshaller from MQTemplateProtocol and
instead extract the common code into a free function.
Fabian