Hello,
I have been searching ProtoBufs documentation for hours and I could
not find a simple feature: how to write a generic type, which is
determined at runtime, similar to "object". As far as I can see all
values need to have specific types. Suppose I want to serialize an
object:
message Objec
On Apr 3, 8:08 pm, Kenton Varda wrote:
> I'm guessing you enabled some kind of compression for the FI encoding? Note
> that protocol buffers, while compact, do not actually apply any sort of
> compression themselves. For repetitive data or data containing a lot of
> text strings, applying zlib
Here are the errors:
BackupComm error LNK2005: "public: void __thiscall std::ios_base::clear
(int,bool)" (?cl...@ios_base@std@@qaex...@z) already defined in
Service.obj
BackupComm error LNK2005: "public: virtual __thiscall
std::ios_base::~ios_base(void)" (??1ios_b...@std@@u...@xz) already
defined
I think part of my problem was using precompiled headers in the
project. I've removed that option and recreated my project, but I
still get these linker errors:
backupcomm error LNK2019: unresolved external symbol "public: static
class google::protobuf::MessageFactory * __cdecl
google::protobuf::
It appears you are not linking against libprotobuf.lib.
On Wed, Apr 8, 2009 at 8:28 AM, wrote:
>
> I think part of my problem was using precompiled headers in the
> project. I've removed that option and recreated my project, but I
> still get these linker errors:
>
> backupcomm error LNK2019: un
On Tue, Apr 7, 2009 at 10:15 PM, ShirishKul wrote:
> I do not have any sample file to share with you. But I think FI
> handles the repeatative attribute-values.
OK, well, I call that "compression". Try gzipping the final protobuf and FI
documents and comparing the compressed sizes. The protob
It's very likely that your problem can be better solved using extensions.
http://code.google.com/apis/protocolbuffers/docs/proto.html#extensions
For example, you could do:
message Field {
required string name = 1;
optional int32 int32_value = 2;
optional int64 int64_value = 3;
o
I don't know how else to link to libprotobuf.lib. Here's the resulting
command lines of the options I've tried:
/LIBPATH :"C:\Development\Libraries\lib" contains the output of the
files built using the project files in vsprojects folder included in
the protobuf source.
First, I'm not speciyfing
On Wed, Apr 8, 2009 at 2:01 PM, wrote:
>
> I don't know how else to link to libprotobuf.lib. Here's the resulting
> command lines of the options I've tried:
>
> /LIBPATH :"C:\Development\Libraries\lib" contains the output of the
> files built using the project files in vsprojects folder included
You can use "svn diff" to produce a single patch file that contains both
parts of this change.
On Tue, Apr 7, 2009 at 10:01 PM, Wink Saville wrote:
> There is a bug in the initialization of the log_silencer_count_mutex_ in
> common.cc.
> Currently it is initialized because it is a global object,
Although I see the decsriptor.cc part isn't meant to be submitted...
On Wed, Apr 8, 2009 at 2:59 PM, Kenton Varda wrote:
> You can use "svn diff" to produce a single patch file that contains both
> parts of this change.
>
>
> On Tue, Apr 7, 2009 at 10:01 PM, Wink Saville wrote:
>
>> There is a
Well, now I'm convinced my problem was directly related to visual
studio. I originally started this project in VS2003 so I wouldn't have
to cart around a bunch of vc90 dlls. However, I build libprotobuf in
vs 2008. That threw me off at one point, I thought my problems were
related to the version d
I don't think a libprotobuf compiled with VS2008 will work correctly with a
project compiled in VS2003. Microsoft has a tendency to change the layout
of their STL objects frequently (even debug vs. release versions of the
standard library have different STL layouts), and libprotobuf uses STL
exten
That must have been the problem. This time, I started over and only
used 2008, everything worked fine.
On Apr 8, 5:07 pm, Kenton Varda wrote:
> I don't think a libprotobuf compiled with VS2008 will work correctly with a
> project compiled in VS2003. Microsoft has a tendency to change the layout
Correct.
Where you able to duplicate the problem.
On Wed, Apr 8, 2009 at 2:59 PM, Kenton Varda wrote:
> Although I see the decsriptor.cc part isn't meant to be submitted...
>
>
> On Wed, Apr 8, 2009 at 2:59 PM, Kenton Varda wrote:
>
>> You can use "svn diff" to produce a single patch file that
15 matches
Mail list logo
