A DescriptorPool actually sets on top of a DescritporDatabase.  In theory, a
DescriptorDatabase could contain an infinite number of types.  In real life,
we have DescriptorDatabase implementations backed by remote servers
containing large databases of types.  There's also
SourceFileDescriptorDatabase, which searches for files on the filesystem
on-demand.

A mechanism for iterating over these, therefore, doesn't always make sense.

I also feel that iterating over all types compiled into the binary isn't
usually a good idea, because generally it's bad to create behavior that
changes depending on what's linked in.  A better idea is to have your caller
provide you with a collection of Descriptors or FileDescriptors covering
types that it is interested in.  You can then scan those easily.

BTW, it's almost always wrong to call generated_pool() or
generated_factory() directly in library code -- you should ask the caller to
provide you with a pool and a factory.  This is a case of singletons being
evil:
  http://www.object-oriented-security.org/lets-argue/singletons

I actually wish I'd never offered these singletons.  The C++ code should
have been designed more like the Java code, where there is no central
descriptor pool or message factory.  Oh well.

On Thu, Jun 17, 2010 at 9:35 AM, Louis-Marie <lm.mou...@gmail.com> wrote:

> Hi all,
>
> I'm writing a C++ library function which reads protocol buffer objects
> from an input stream and returns an abstract Message object to caller.
> When descriptors are not known at compile-time, I use a
> DescriptorPool::BuildFile() call to load them dynamically. I inspect
> each loaded file to find messages which are valid top-level objects to
> be parsed from my input stream (they are tagged with a custom option).
>
> However, library client may want to use objects he knows at compile-
> time (typically dynamic_cast'ing them, rather than getting
> DynamicMessage instances), so I would like to inspect the
> generated_pool itself to index valid descriptors it might contain.
> This way, I could build objects based on descriptions from
> generated_pool.
>
> I can't figure out how to browse a DesciptorPool (I would need a way
> to iterate over the whole list of FileDescriptor objects). Looking at
> sources, it seems it would not be so difficult to implement that, but
> I probably miss something...
>
> I wrote a small protoc plugin which inserts self-registration code in
> each generated *.pb.cc file. This way, I can use the resulting file
> list to get the descriptor using DescriptorPool::generated_pool()-
> >FindFileByName() but it is totally redundant with generated pool's
> built-in registration system.
>
> What do you think would be the good solution to do that?
>
> Thanks,
>
> Louis-Marie
>
> --
> 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<protobuf%2bunsubscr...@googlegroups.com>
> .
> 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 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.

Reply via email to