Re: Runtime import proto (with extensions) fails with DLL use

2009-10-01 Thread Carlo Medas 

Dears,

I've managed to build libprotobuf.dll, the dynamic version, and this
fixed the issue.

But now MY code is not working at all.

I would like to manually enumerate the available extensions to my
RpcMessage. This is easily done by using an ExtensionFactory in Java
code.
In C++ it's not there, so we tried to use the
google::protobuf::Descriptor, but neither the extension_count and
field_count keep track of the created extensions.

Do we have to manually manage the set of known extensions?
Pretending that I managed to know the field assigned to that
extension, the following code is going to work in order to assing the
value to that extension field by using reflection?

const google::protobuf::Reflection* reflection =
rpcMessage.GetReflection();
google::protobuf::Message* msg = reflection-MutableMessage
(rpcMessage, field);
msg-CopyFrom(*response);


Thanks in advance again.

Carlo

On 1 Ott, 09:46, Carlo Medas carlome...@gmail.com wrote:
 Dears,

 we have rpc.proto with a base message, then mathpeer.proto with
 messages that extend the base RpcMessage.

 The rpc.proto is built and compiled inside a core.dll, using the --
 cpp_out=dllexport_decl directive you explained us before.
 The mathpeer.proto is built inside an exe which is linked against
 core.dll and libprotobuf (static version).

 We get the folowing errors as soon as we try to use some message of
 the mathpeer proto:

 libprotobuf ERROR ..\src\google\protobuf\descriptor.cc:2219] Invalid
 proto descriptor for file mathpeer.proto:
 libprotobuf ERROR ..\src\google\protobuf\descriptor.cc:]
 mathpeer.proto: Import rpc.proto was not found or had errors.
 libprotobuf ERROR ..\src\google\protobuf\descriptor.cc:]
 overlook.rpc.math.peerInfoRequest: .overlook.rpc.RpcMessage is not
 defined.
 libprotobuf ERROR ..\src\google\protobuf\descriptor.cc:]
 overlook.rpc.math.peerInfoResponse: .overlook.rpc.RpcMessage is not
 defined.
 libprotobuf FATAL ..\..\..\..\src\tool\rpctest\mathpeer.pb.cc:33]
 CHECK failed: file != NULL:

 It seems to me that the extension registry is not the same for DLL and
 EXE, or something like that.
 As I've been reading some other thread, could this be caused by the
 fact that we are linking to a static libprotobuf in both DLL and exe?

 Thanks in advance,

 Carlo Medas
--~--~-~--~~~---~--~~
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: Runtime import proto (with extensions) fails with DLL use

2009-10-01 Thread Carlo Medas 

Dear Kenton,

thanks for prompt reply and deep explaination.

The descriptor-file()-pool()-FindAllExtensions(...)  was exactly
what we've been looking for, in order to enumerate all available
extensions of an extendee message.

Now everything works fine. Thanks again for precious work.

On 1 Ott, 13:05, Kenton Varda ken...@google.com wrote:
 On Thu, Oct 1, 2009 at 3:39 AM, Carlo Medas carlome...@gmail.com wrote:
  I would like to manually enumerate the available extensions to my
  RpcMessage. This is easily done by using an ExtensionFactory in Java
  code.

 What's ExtensionFactory?  Do you mean ExtensionRegistry?  But it doesn't
 allow you to enumerate extensions, only search for specific ones.

  In C++ it's not there, so we tried to use the
  google::protobuf::Descriptor, but neither the extension_count and
  field_count keep track of the created extensions.

 extension_count keeps track of extensions declared within the message's
 scope.  E.g. I can do:

   message Foo {
     extend Bar {
       optional int32 baz = 1;
     }
   }

 Here, baz is declared within Foo's scope, even though it is extending Bar.

 My guess is that you want to know all the extensions which are extending
 your Descriptor, not all of the extensions declared within the scope of your
 Descriptor.  In that case, you have two options:

 1) DescriptorPool (which you can get using descriptor-file()-pool()) has
 methods for searching for extensions.

 2) The Reflection interface for a particular message (returned by
 message.GetReflection()) has methods for searching for extensions.

 However, like in Java, you can not iterate over all known extensions.  You
 can only search for particular ones.

  Pretending that I managed to know the field assigned to that
  extension, the following code is going to work in order to assing the
  value to that extension field by using reflection?

         const google::protobuf::Reflection* reflection =
  rpcMessage.GetReflection();
         google::protobuf::Message* msg = reflection-MutableMessage
  (rpcMessage, field);
         msg-CopyFrom(*response);

 Yes.  The reflection interface treats regular fields and extensions exactly
 the same.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---