Hi Jens,
That's an interesting proposition, sorry for the delayed answer, but if I'm
not wrong with your example it would generate exceptions independently of
the side you update first.
Since the i16 side wouldn't be able to read the i32's that would came
either as an input or output of your function. Therefore, to make it work
we would have to be able to read larger numbers too, and cast them down.
This could be a little tricky for an user to understand the results, and
increase the complexity of the compiler quite a bit.
However, it's theoretically possible and I don't think it would affect the
performance that much.
- Henrique
On 15 March 2013 19:57, Jens Geyer <jensge...@hotmail.com> wrote:
> I think TCompactProtocol uses var length ints, achieving
>> something similar to what you mentioned.
>>
>
> Yep, but good point anyway.
>
>
> Not that this would help w/ the original issue.
>>
>
> Of course, because it is only "something similar" and suffers from the
> same limitations. What the OP suggests and/or what I was thinking of is
> something like this (this would be generated C++ code for one field) :
>
> case 1:
> switch( ftype) {
> case ::apache::thrift::protocol::T_**BYTE:
> int8_t tmp4710;
> xfer += iprot->readByte(tmp4710);
> this->thing = tmp4710;
> this->__isset.thing = true;
> break;
> case ::apache::thrift::protocol::T_**I16:
> int16_t tmp4711;
> xfer += iprot->readI16(tmp4711);
> this->thing = tmp4711;
> this->__isset.thing = true;
> break;
>
> case ::apache::thrift::protocol::T_**I32:
> xfer += iprot->readI32(this->thing);
> this->__isset.thing = true;
> break;
> case ::apache::thrift::protocol::T_**I64:
> throw TProtocolException(**TProtocolException::SIZE_**LIMIT);
> else
> xfer += iprot->skip(ftype);
> break;
> }
> break;
>
> and similarly with the generated write() code. This way all protocols
> would profit form it (except for those where it makes no difference with
> regard to serialized data, such as JSON).
>
> The two biggest problem that I see are a) it breaks compatibility, so we
> have to increase the VERSION number, and b) it might affect overall
> serialization/deserialization performance.
>
> Jens
>
>
>
>
>
>
>
>
>
>
