As a Delphi developper I didn't look on the parsing code, I've made it
from scratch :)
I didn't see that fixed32 is also a message type, I guess it was used to
store negative integers to avoid big varint.
my Delphi code test the wire type for each readed value...it's a mistake :)
function TProtoBufReader.GetInt32(Sign: TSign): Integer;
begin
case FID and 7 of
0: if Sign = Signed then
Result := GetSignedVarInt
else
Result := Integer(FU64);
1,
5: Result := Integer(FU64);
else raise Exception.Create('Int32 expected');
end;
end;
function TProtoBufReader.GetInt64(Sign: TSign): Int64;
begin
case FID and 7 of
0 : if Sign = Signed then
Result := GetSignedVarInt
else
Result := Int64(FU64);
1,
5 : Result := Int64(FU64);
else raise Exception.Create('Int64 expected');
end;
end;
function TProtoBufReader.GetString: string;
var
s: UTF8String;
begin
if (FID and 7) <> 2 then
raise Exception.Create('String expected');
SetLength(s, FU64);
FStream.ReadBuffer(s[1], FU64);
Result := string(s);
end;
Le 06/12/2011 12:06, Jason Hsueh a écrit :
The difficulty with this is that the parser would need to accept two
distinct wire types for each integer field. The parsing code would
become:
if tag number is x:
if wire type is positive varint { ... }
if wire type is negative varint { ... }
This leads to larger code size and has potential performance impact.
I'm not sure if experiments were ever done with this sort of approach
- the penalties may not be too bad - for packed repeated fields, a
change was made to allow the parser to accept either the packed or
unpacked format, and this was acceptable. However, the impact may be
greater for singular integer fields, which tend to be more prevalent,
at least within Google. In any event, changes to the wire format are
very infrequent (note that the zigzag encoding didn't actually change
the wire format, just how the varint wire type was interpreted);
there'd have to be a pretty significant impact in wire size to make
this sort of change at this point.
On Fri, Dec 2, 2011 at 8:04 PM, Paul TOTH <[email protected]
<mailto:[email protected]>> wrote:
Protocol Buffers is great, but there's something I don't understand.
VarInt is great to store positive integers
sint32/64 are stored as "zigzag" VarInt
why int32/64 aren't stored as :
1) VarInt when positive (type 0)
2) NegativeVarIn when negative (a new type 6 that store the opposite
value as a positive VarInt)
Then you don't need to specify sint32/64 in the Message and integers
will be stored in the most efficient way each time, regardless of they
sign.
Regards from France
Paul TOTH
--
You received this message because you are subscribed to the Google
Groups "Protocol Buffers" group.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:protobuf%[email protected]>.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
--
You received this message because you are subscribed to the Google Groups "Protocol
Buffers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
