Re: [protobuf] Re: This type does not have extensions
2010/10/6 Kenton Varda ken...@google.com: This exception shouldn't be possible. If you can produce a small, self-contained program that demonstrates the problem, I could debug it. Please make sure that the program is small (no more than one .proto file and one source file) and runs quickly. Probably the easiest thing to do is record a sample message that produces this error and write a little program that tries to parse those exact bytes. I did that and failed to reproduce the problem. My theory is that I was parsing a message of type B, where B is a extension of A, and doing this before parsing any messag of type A. I rewrote my code so I didn't have to serialize any extension types, and then the problem disappeared. When I was debugging this, I remember seeing that a field defaultInstance was null, and this seemed to cause protobuf to create a builder for a GeneratedMessage, instead of a ExtensionMessage. After that observation, I took a few steps back and rewrote my code to avoid serializing extension types. I'll try to construct a smaller test program when I get back to work tomorrow. -- /Jesper -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
Re: Java compiler warning
Fair enough. On Fri, Oct 9, 2009 at 9:10 PM, Kenton Varda ken...@google.com wrote: Unfortunately, we (read: I) don't really have time to chase warnings. If you want it fixed, submit a patch. Otherwise, ignore it -- the code does the right thing. On Fri, Oct 9, 2009 at 1:16 AM, Jesper jesper.eskil...@gmail.com wrote: The Eclipse Java compiler issues a warning about a raw type: Description Resource Path Location Type GeneratedMessage.ExtendableMessage.ExtensionWriter is a raw type. References to generic type GeneratedMessage.ExtendableMessageMessageType.ExtensionWriter should be parameterized CDP.java /com.iar.ide.debugger.cdp/src/com/iar/ide/ debugger/cdp/proto line 17913 Java Problem Should I submit a bug about this, or is it already known? (protobuf-2.2.0) -- /Jesper --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: Java compiler warning
On Fri, Oct 9, 2009 at 4:20 PM, Henner Zeller h.zel...@acm.org wrote: On Fri, Oct 9, 2009 at 01:16, Jesper jesper.eskil...@gmail.com wrote: The Eclipse Java compiler issues a warning about a raw type: Description Resource Path Location Type GeneratedMessage.ExtendableMessage.ExtensionWriter is a raw type. References to generic type GeneratedMessage.ExtendableMessageMessageType.ExtensionWriter should be parameterized CDP.java /com.iar.ide.debugger.cdp/src/com/iar/ide/ debugger/cdp/proto line 17913 Java Problem Should I submit a bug about this, or is it already known? If you're already that close, it is probably faster to send a patch. Close? I'm just reporting what the compiler says. I haven't even begun hunting down where/how that should be fixed. Maybe its easy, I just wanted to see if this was a known bug. -- /Jesper --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: Parsing messages in C++ with extensions
On Thu, Sep 3, 2009 at 6:56 PM, Kenton Vardaken...@google.com wrote: You want: const UnknownFieldSet set = cmd.GetReflection()-GetUnknownFields(cmd); Ok, so if I have function which receives a message which as an unknown field which I need to parse into a real message, how should I do? (The documentation is a little fuzzy on this...) I tried to call ParseFromString() on the string returned by length_delimited(), but that just crashed. const UnknownFieldSet set = cmd.unknown_fields(); const UnknownField f = set.field(0); const std::string buf = f.length_delimited(); listwindow::ListWindowCommand lwc; lwc.ParseFromString(buf); -- /Jesper --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: Parsing messages in C++ with extensions
On Fri, Aug 28, 2009 at 6:42 PM, Kenton Vardaken...@google.com wrote:
To answer your specific question, BTW, yes, you can inspect the contents of
UnknownFieldSet. Every message object has methods unknown_fields() and
mutable_unkown_fields() which return the UnknownFieldSet. The API is
described here:
http://code.google.com/apis/protocolbuffers/docs/reference/cpp/google.protobuf.unknown_field_set.html
I'm probably missing something, but I get a complation error when
trying to access the unknown fields of a message:
Error 1 error C2248:
'google::protobuf::UnknownFieldSet::UnknownFieldSet' : cannot access
private member declared in class 'google::protobuf::UnknownFieldSet';
e:\dev\ide-platform\core\ide\protobuf\src\google/protobuf/unknown_field_set.h(124)
: see declaration of
'google::protobuf::UnknownFieldSet::UnknownFieldSet';
e:\dev\ide-platform\core\ide\protobuf\src\google/protobuf/unknown_field_set.h(63)
: see declaration of
'google::protobuf::UnknownFieldSet'
e:\dev\ide-platform\core\ide\CSpyServer\src\model\CssListWindowService.cpp
21
The code looks like this:
void
foo(const cdp::DebugCommand cmd)
{
UnknownFieldSet set = cmd.GetReflection()-GetUnknownFields(cmd);
}
--
/Jesper
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---
Re: Parsing messages in C++ with extensions
On Fri, Aug 28, 2009 at 1:28 AM, Kenton Vardaken...@google.com wrote: Yep, it's a very annoying problem. The solution I prefer is to add a dummy usage of one of the classes in your .proto somewhere high-up in your program, in a place that should logically know that the file is needed. This is really not feasible. There is no such place, unfortunately. BTW, if you aren't actually explicitly using the extension anywhere, then the only reason to force it to be linked in is if you want it to appear correctly when using reflection or TextFormat. Otherwise you should just let it go into the UnknownFieldSet. The situation is this: I have a main program which parses incoming messages, and some of these messages have extensions set. These extensions are (sometimes) only known to plugins to the main program. The incoming message has an identifier so that the main program knows which plugin it should send the message to, but the main program itself doesn't know anything about the plugin. The problem I had was that when the message was passed to the plugin, the plugin fails to get the extension, i.e. the extension field was unset (i.e. HasExtension(foo::foo_ext) returned false). Does the UnknownFieldSet allow the plugin to extract the unknown field? The original solution to this I had before I read up on extensions was to store the messages to/from the plugins as seralized byte-streams in the top-level package. This actually worked fine, with the exception of having to encode/copy the message twice at both ends. -- /Jesper --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: Parsing messages in C++ with extensions
On Fri, Aug 28, 2009 at 6:42 PM, Kenton Vardaken...@google.com wrote: Ouch, this hole is probably a lot deeper than it looks. First let me review some things which you may already know... I assume these plugins are DLLs. Do you load and unload these plugins at runtime, or just at startup? If you unload them at runtime, then each one needs to be statically linked against its own instance of the protobuf library (probably the lite library!), because libprotobuf is not designed to allow individual protos to be unloaded without shutting down the entire library. But if each plugin has its own instance, then you cannot pass protobuf objects to the plugin. You can only pass encoded messages, which it must parse itself. If you do load the plugins for the entire life of the process, then things are a little more flexible. In this case, you can share a single instance of libprotobuf among all of them and your app as long as everyone links against it as a DLL. (Though, in this case all plugins must be linked against the exact same version of libprotobuf, which may be a problem if they are developed by separate groups.) Now, getting back to extensions, if you are going with the first option, then obviously your app can recognize extensions defined within the plugins, because they use a separate instance of libprotobuf. But it doesn't matter, because you have to re-serialize the messages before sending them to the plugins anyway, and they will do their own parsing with the extensions recognized. If you are going with the second option (sharing a common instance of libprotobuf), then the plugin *should* have registered its extensions with that common instance at startup, and therefore it should be parsing correctly. To answer your specific question, BTW, yes, you can inspect the contents of UnknownFieldSet. Every message object has methods unknown_fields() and mutable_unkown_fields() which return the UnknownFieldSet. The API is described here: http://code.google.com/apis/protocolbuffers/docs/reference/cpp/google.protobuf.unknown_field_set.html Ok, thanks for the detailed explanation. I think I have enough info on this for the time being. -- /Jesper --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Fwd: Parsing messages in C++ with extensions
I keep clicking on reply instead of reply all... -- Forwarded message -- From: Jesper Eskilson jes...@eskilson.se Date: Thu, Aug 27, 2009 at 9:23 AM Subject: Re: Parsing messages in C++ with extensions To: Kenton Varda ken...@google.com On Thu, Aug 27, 2009 at 12:18 AM, Kenton Vardaken...@google.com wrote: Some linkers will drop object files that aren't referenced from anywhere, so if your code doesn't actually use anything from the .proto file defining the extension, it might not be linked in, and thus won't be in the registry. This is one of the common problems that make me wish we had an explicit ExtensionRegistry in C++... Otherwise, I don't know what your problem might be. If you can narrow it down to a small self-contained example I could debug it. Well, hm. I don't seem to be linking with the defining code. That would probably explain it. Would an explicit extension-registry be difficult to implement? What's the recommended way of solving the problem? Linking in all the protocol definitions in the same module is something I'd like to avoid. Is there a way I can extract the unknown field and pass it to the defining module for further parsing? -- /Jesper -- /Jesper --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: Parsing messages in C++ with extensions
On Thu, Aug 27, 2009 at 12:18 AM, Kenton Vardaken...@google.com wrote: Some linkers will drop object files that aren't referenced from anywhere, so if your code doesn't actually use anything from the .proto file defining the extension, it might not be linked in, and thus won't be in the registry. This is one of the common problems that make me wish we had an explicit ExtensionRegistry in C++... Otherwise, I don't know what your problem might be. If you can narrow it down to a small self-contained example I could debug it. You're right. I first needed to link all of the *.pb.cc files into library doing the parsing, but as you said, MSVC drops the code unless I explicitly refer to some code in it. This is really annoying. -- /Jesper --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: Parsing messages in C++ with extensions
On Wed, Aug 26, 2009 at 10:38 PM, Kenton Vardaken...@google.com wrote: In C++ all compiled-in extensions are automatically registered in a global registry which is used automatically by all compiled-in classes. I now regret this design decision due to a number of subtle problems it creates, but for you it means that you don't have to do anything special. I wonder why it isn't working for me, then. I'm serializing an object from Java with an extension set, but when parsing it in C++, the extension field is unset. I'll have to dig some deeper tomorrow. (Annoying time-zone lag. You're replying just around my bedtime. :-)) -- /Jesper --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
C++ compilation errors when using extensions
I'm getting a C++ template error message I'm having trouble
understanding. I have two .proto files, one called cdp.proto which
defines ServiceCommand:
message ServiceCommand
{
...
extensions 200 to max;
}
This is then extended in libsupport.proto, like this:
message LibSupportMessage {
...
}
extend cdp.ServiceCommand {
optional LibSupportMessage libsupport = 200;
}
The error occurs when I try to create a ServiceCommand with a
LibSupportMessage extension:
libsupport::LibSupportMessage msg;
... initialize msg ...
cdp::ServiceCommand srvCmd;
// The next line triggers the compilation error.
srvCmd.SetExtension(libsupport::libsupport, msg);
If I comment out the SetExtension() call, the error disappears. The
error is the following:
1e:\dev\ide-platform\core\ide\build.vs8\protobuf_cpp\cdp.pb.h(4998) :
error C2039: 'Set' : is not a member of
'google::protobuf::internal::MessageTypeTraitsType with
[Type=libsupport::LibSupportMessage]';
..\..\LibSupport\service\SrvProtobuf.cpp(91) : see reference to
function template instantiation 'void
cdp::ServiceCommand::SetExtensiongoogle::protobuf::internal::MessageTypeTraitsType,11,false(const
google::protobuf::internal::ExtensionIdentifierExtendeeType,TypeTraitsType,field_type,is_packed
,const libsupport::LibSupportMessage ) with
[Type=libsupport::LibSupportMessage,ExtendeeType=cdp::ServiceCommand,TypeTraitsType=google::protobuf::internal::MessageTypeTraitslibsupport::LibSupportMessage,field_type=11,is_packed=false]'
being compiled
1e:\dev\ide-platform\core\ide\build.vs8\protobuf_cpp\cdp.pb.h(4998) :
error C3861: 'Set': identifier not found
Any ideas?
--
/Jesper
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---
Re: C++ compilation errors when using extensions
On Tue, Aug 25, 2009 at 10:51 AM, Jesper Eskilsonjes...@eskilson.se wrote: I'm getting a C++ template error message I'm having trouble understanding. I have two .proto files, one called cdp.proto which defines ServiceCommand: Problem solved. I realized that I need to use the GenericExtension() method just like when setting regular fields. -- /Jesper --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: assertion crash with debug build on windows
On Thu, Jul 16, 2009 at 11:14 AM, Mr Moosestephan.men...@gmail.com wrote: It is found! After 4 interesting days of debugging the bastard I realized that I rercently had to add 3 preprocessor defines to my build system: _CRT_SECURE_NO_WARNINGS _SECURE_SCL=0 _HAS_ITERATOR_DEBUGGING=0 If they are missing, many things[tm] won't work properly in debug build. Things such as several boost components for instance. So I set them defines and forgot about them. Hence the crashes in libprotobuf. Now I added same defines to the libprotobuf target in the .sln file of 2.1.0. After a complete rebuild things work fine. Which one of the defines was responsible and why remains obscure but I tend to think _SECURE_SCL might alter headers and type definitions to the using app and the lib are using differently sized types. Yes, indeed. Changing _SECURE_SCL causes layout-changes in *all* STL containers. If you get weird crashes inside STL-containers, this is the first thing to check. Cheers, Stephan On 16 Jul., 09:29, Mr Moose stephan.men...@gmail.com wrote: OK, just for the records: Now I can be really sure. I've deleted everything that remotely resembles a release build and changed my build system so it won't create any and work without. And still the bug occurs. So I don't think it is related to Microsoft runtime issues. Cheers, Stephan On 16 Jul., 08:33, Mr Moose stephan.men...@gmail.com wrote: Kenton, well, I checked this over and over again and I really think I did make sure. I also checked the linker settings for all other libs I link against and they are all set to Debug. Also, this is the same build environment I used with 2.0.3. where it did work. On the other hand, it's Microsoft so you can never be really sure what's going on. Anyway, is there any other possible explanation for said crashes? Cheers, Stephan On 15 Jul., 20:25, Kenton Varda ken...@google.com wrote: Did you make sure to compile your debug build against a debug build of libprotobuf? MSVC fails miserably when trying to mix and match debug vs. release, apparently because the STL classes have different representations between the two. -- /Jesper #include witty-quote.h --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: Windows HANDLE and sockets / named pipes
(Sorry Kenton, I missed adding the list as recipient...)
We're using a very simple approach where we send only one type of
message containing a type-enum and one or more optional fields (I
think this technique is described in the manual). In order to be able
to read the message in full before parsing it, we first send a 32-bit
integer containing the size of the message, and then read that many
bytes. Really not very complicated.
On Fri, Jun 19, 2009 at 10:53 AM, Kenton Vardaken...@google.com wrote:
No, protocol buffers are not self-describing. The receiver needs to know
what type it is receiving, or you need to send the type information over the
wire separately.
On Fri, Jun 19, 2009 at 1:10 AM, brodie brofi...@gmail.com wrote:
If the entire message needs to be in the buffer at one time before it
can be parsed out, then it makes parsing out the messages easier. i.e.
either the message is complete or not. Is there an interface to parse
a generic message from the buffer? There doesn't seem to be. I'm
envisaging usage something like this...
something buf;
Message * msg
while (receiveData(buf)) {
rc = Factory::parse(buf, msg);
if (rc == INCOMPLETE) continue;
switch (msg-type()) {
... process ...
}
}
The proto2 RPC doesn't appear to fit my usages because my message
stream is not strictly request/response. There can be multiple request
messages in a row, ditto for responses.
Regards,
Brodie
On Jun 19, 12:47 pm, Kenton Varda ken...@google.com wrote:
On Thu, Jun 18, 2009 at 8:47 PM, Kenton Varda ken...@google.com wrote:
Note that the protocol buffer parser is not asynchronous. That means
you
either need to feed it an entire message at once, or it will need to
block
waiting for mode data to arrive on
s/mode/more
the input stream. So if you want to do something asynchronous, you
best
bet is probably to do your own buffering until you have received an
entire
message, then pass the bytes off to the protobuf parser. You probably
won't
need to implement any custom ZeroCopyStreams for that.
On Thu, Jun 18, 2009 at 8:30 PM, brodie brofi...@gmail.com wrote:
Hi all,
Has anyone done any work to create a stream implementation for async
use? In particular, Windows async sockets or async named pipes?
I'm planning to implement PB as the messaging layer on top of a
Windows sockets transport layer (therefore using HANDLE instead of a
file descripter). We may additionally make this layer swappable with
named pipes (also a HANDLE). Transport in both cases will be done
async. On Linux/OSX we will just use async sockets.
It would be nice if someone has already done some work in this area
that I can leverage/build on. Any pointers?
Regards,
Brodie
--
/Jesper
#include witty-quote.h
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---
Re: Thoughts on a cleaner Java protocol buffer compiler.
On Wed, Apr 29, 2009 at 11:27 PM, Kenton Varda ken...@google.com wrote: My thinking on the current format is that Java developers are going to look at this and be all WTF and then walk away... maybe it's just me ;) That's not the reaction I've seen from most Java devs. +1 from me. The protobufs API has been wonderful to use, from Java and C++. -- /Jesper --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: Crash while initializing StaticDescriptorInitializer
On Thu, Mar 26, 2009 at 6:57 PM, Kenton Varda ken...@google.com wrote: On Thu, Mar 26, 2009 at 9:28 AM, Jesper jesper.eskil...@gmail.com wrote: I think so, but I'll double-check. (Wouldn't that have showed up when libprotobuf.lib was linked into the exe?) Unfortunately, probably not. Strange crashes at runtime are the usual symptom. :( It turned out to be caused by a mismatch in using _SECURE_SCL, i.e. checked iterators. Just to add to the Debug/Release problems, Microsoft has added extra defines which must not be mixed -- _SECURE_SCL affects the binary layout of STL containers, so it has to be defined the same way everywhere, and unfortunately the code I'm working on has a non-default setting for _SECURE_SCL. Thanks anyway for all the help. (BTW: I created a set of CMake (http://cmake.org) build files for Protobufs, in case you're interested in not maintaining parallell Makefiles/project files for Linux/Windows.) -- /Jesper --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: Crash while initializing StaticDescriptorInitializer
On Fri, Mar 27, 2009 at 8:08 PM, Kenton Varda ken...@google.com wrote: On Fri, Mar 27, 2009 at 3:33 AM, Jesper Eskilson jes...@eskilson.se wrote: (BTW: I created a set of CMake (http://cmake.org) build files for Protobufs, in case you're interested in not maintaining parallell Makefiles/project files for Linux/Windows.) We considered using cmake originally, but decided it was more important to avoid making users download extra tools before they could compile protocol buffers. So I continue to toil away, maintaining MSVC project files, as silly as they are... That is one major hurdle for getting people to like CMake; you need an extra tool before you get your buildfiles. If CMake just could create relocatable project files, things would look much brighter. -- /Jesper --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Crash while initializing StaticDescriptorInitializer
I have libprotobuf.lib linked into a DLL, and when loading the DLL, I
get the following crash. (Noteworthy is that I previously hade the
same code linked into a single exe, and then it worked without any
problem.)
Any clues about how I can solve this?
CSpyServerLib.dll!
std::_Treestd::_Tset_traitsstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,std::lessstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,std::allocatorstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,0 ::erase
(std::_Treestd::_Tset_traitsstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,std::lessstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,std::allocatorstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,0 ::iterator _First=Bad Ptr,
std::_Treestd::_Tset_traitsstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,std::lessstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,std::allocatorstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,0 ::iterator _Last=) Line 926 + 0xb bytes C++
CSpyServerLib.dll!google::protobuf::DescriptorBuilder::BuildFile
(const google::protobuf::FileDescriptorProto proto={...}, void
(const google::protobuf::FileDescriptor *)*
descriptor_assigner=0x00d7c0e0) Line 2420 + 0x25 bytes C++
CSpyServerLib.dll!
google::protobuf::DescriptorPool::InternalBuildGeneratedFile(const
void * data=0x00db31b8, int size=3449, void (const
google::protobuf::FileDescriptor *)* descriptor_assigner=0x00d7c0e0)
Line 1962 + 0x2f bytes C++
CSpyServerLib.dll!
google::protobuf::protobuf_BuildDesc_google_2fprotobuf_2fdescriptor_2eproto
() Line 547C++
CSpyServerLib.dll!google::protobuf::MessageOptions::default_instance
() Line 3743 C++
CSpyServerLib.dll!
google::protobuf::DescriptorBuilder::CrossLinkMessage
(google::protobuf::Descriptor * message=0x00bbf448, const
google::protobuf::DescriptorProto proto={...}) Line 2890 + 0x5
bytes C++
CSpyServerLib.dll!google::protobuf::DescriptorBuilder::CrossLinkFile
(google::protobuf::FileDescriptor * file=0x00bbf2c8, const
google::protobuf::FileDescriptorProto proto={...}) Line 2871 + 0x18
bytes C++
CSpyServerLib.dll!google::protobuf::DescriptorBuilder::BuildFile
(const google::protobuf::FileDescriptorProto proto={...}, void
(const google::protobuf::FileDescriptor *)*
descriptor_assigner=0x00ccb7f0) Line 2400 C++
CSpyServerLib.dll!
google::protobuf::DescriptorPool::InternalBuildGeneratedFile(const
void * data=0x00da9a18, int size=6815, void (const
google::protobuf::FileDescriptor *)* descriptor_assigner=0x00ccb7f0)
Line 1962 + 0x2f bytes C++
CSpyServerLib.dll!cdp::`dynamic initializer for
'static_descriptor_initializer_cdp_2eproto_''() Line 1293 + 0x42 bytes C++
msvcr80.dll!78131742()
...
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---
