[protobuf] Re: Issue 220 in protobuf: TextFormat:Parser cannot parse strings with colon?
Comment #3 on issue 220 by david.vo...@gmail.com: TextFormat:Parser cannot parse strings with colon? http://code.google.com/p/protobuf/issues/detail?id=220 Sorry for the late answer. (I was offline for a little while.) We tested our code and your example too. I really sorry but it seems that we had a bug and your code is good. Sorry for the false report. -- 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: [protobuf] DescriptorPool::BuildFile() seems not parsing nested messages in order
Kenton:
I really sent you a only a part of the complete RecordHeader message, since
I was focusing on "nested message not getting parsed" issue for this
particular message. Indeed my complete proto file is a large one. I have
attached the truncated proto file containing this complete message only
for reference with this mail (plese see attachment
'dynamicProtoMessages.proto '.
I had used Parser and Importer earlier and generated the FileDescriptor in a
class “CMessageParser” member function as below:
//***//
class PacketTracerErrorFileErrorCollector:
publicgoogle::protobuf::compiler::MultiFileErrorCollector
{
...
};
const google::protobuf::FileDescriptor* CMessageParser
::generateMessageFileDescriptor()
{
std::pair filePair;
google::protobuf::compiler::DiskSourceTree source_tree;
source_tree.MapPath(/*filePair.first*/"", "."/*filePair.second*/);
PacketTracerErrorFileErrorCollector error_collector;//Defined above
google::protobuf::compiler::Importer importer(&source_tree,
&error_collector);
std::string outFileNameString = “dynamicProtoMessages.proto”;
const google::protobuf::FileDescriptor* file_desc =
importer.Import(outFileNameString);
return file_desc;
}
//***//
However, the problem with that approach was, as soon as I returned the
pointer from the FileDescriptor to a client class object of CMessageParser,
the FileDescriptor* becomes NULL or invalid once out of the class and it
becomes useless.
//***//
CMessageParser myParser;
const google::protobuf::FileDescriptor *file_desc =
myParser.generateMessageFileDescriptor();
//file_desc is NULL
//***//
So, I thought, I was following some wrong approach and to retain the File
Descriptors for a long enough period across scopes, I may need the
DescriptorPool, which might have the permanent lifetime for the period of
the application.
Hi Jason:
I am always able to generate the FileDescriptorSet easily, although the
FileDescriptor was never showing completely populated fields when debugging
with Visual studio 2008 Express edition.
I have attached the generated FileDescriptorSet 'dynProtoMessage.dsc' file
along with the proto file containing the above messages with this mail. You
can see even this dsc file (made with simple messages as in the attached
proto file) does not load through DescriptorPool::BuildFile().
This is the function I used to load DescriptorSet:
void CMessageParser
::getMessagesFromDescriptorSet(constgoogle::protobuf::FileDescriptor**
new_file_desc)
{
using namespace google::protobuf;
using namespace google::protobuf::io;
using namespace google::protobuf::compiler;
ifstream desc_file("dynProtoMessage.dsc",ios::in);
if (desc_file.bad()) {
std::cout << "desc file not read...exiting" <<
std::endl;
return;
}
FileDescriptorSet f;
f.ParseFromIstream(&desc_file);
// DescriptorPoolErrorCollector errorCol;
//google::protobuf::SimpleDescriptorDatabase desc_database;
//DescriptorPool descriptor_pool(&errorCol, &desc_database);
DescriptorPool descriptor_pool;
for (int i = 0; i < f.file_size(); ++i) {
descriptor_pool.BuildFile(f.file(i));
}
const Descriptor* descriptor =
descriptor_pool.FindMessageTypeByName("RecordHeader");
// descriptor =>NULL here
//const FileDescriptor* new_file_desc =
descriptor_pool.FindFileByName("dynMessage.dsc");
/*
DynamicMessageFactory factory;
Message* my_message = factory.GetPrototype(descriptor)->New();
delete my_message;
*/
}
Finally, the point raised by Kenton and you that the proto file did not
parse correctly to yield the valid FileDescriptor might be correct, since, I
am generating the .proto file containing the messages on the fly by
converting corresponding tags from my XML file.
When earlier I used a handmade proto file for the messages, which parsed
correctly to provide the descriptors, I was able to stream data into
protocol buffers and use the buffers correctly. I will be inspecting this
file at my end for any typing errors.
Thanks for the answer and for opening this protobuf library on public
domain, though.
Thanks and Regards,
Himanshu
On Thu, Sep 23, 2010 at 7:53 AM, Jason Hsueh wrote:
> It occurred to me that protoc shouldn't accept your file either. Did
> it really compile successfully? What do you actually get in your
> FileDescriptorSet?
>
> On Wednesday, September 22, 2010, Jason Hsueh wrote:
> > 1) I would guess the problem is that the "action" message type refers to
> undefined types eaction_type and ereason. There are probably error messages
> farther up indicating that
Re: [protobuf] DescriptorPool::BuildFile() seems not parsing nested messages in order
P.S.:
Earlier I used cpp files generated from protoc compiler for a small number
of messages and therefore I could get the mutator functions and the
corresponding message classes. Now, however I do not use the cpp approach
since messages and their members are not known in advance.
Regards,
Himanshu
On Thu, Sep 23, 2010 at 3:10 PM, Himanshu Srivastava wrote:
> Kenton:
>
>
> I really sent you a only a part of the complete RecordHeader message, since
> I was focusing on "nested message not getting parsed" issue for this
> particular message. Indeed my complete proto file is a large one. I have
> attached the truncated proto file containing this complete message only
> for reference with this mail (plese see attachment
> 'dynamicProtoMessages.proto '.
>
> I had used Parser and Importer earlier and generated the FileDescriptor in
> a class “CMessageParser” member function as below:
>
>
>
> //***//
>
> class PacketTracerErrorFileErrorCollector:
> publicgoogle::protobuf::compiler::MultiFileErrorCollector
>
> {
>
> ...
>
> };
>
>
>
>
>
> const google::protobuf::FileDescriptor* CMessageParser
> ::generateMessageFileDescriptor()
>
> {
>
> std::pair filePair;
>
> google::protobuf::compiler::DiskSourceTree source_tree;
>
> source_tree.MapPath(/*filePair.first*/"", "."/*filePair.second*/);
>
> PacketTracerErrorFileErrorCollector error_collector;//Defined above
>
> google::protobuf::compiler::Importer importer(&source_tree,
> &error_collector);
>
> std::string outFileNameString = “dynamicProtoMessages.proto”;
> const google::protobuf::FileDescriptor* file_desc =
> importer.Import(outFileNameString);
> return file_desc;
>
> }
>
> //***//
>
>
> However, the problem with that approach was, as soon as I returned the
> pointer from the FileDescriptor to a client class object of
> CMessageParser, the FileDescriptor* becomes NULL or invalid once out of
> the class and it becomes useless.
>
> //***//
>
> CMessageParser myParser;
>
> const google::protobuf::FileDescriptor *file_desc =
> myParser.generateMessageFileDescriptor();
> //file_desc is NULL
>
> //***//
>
>
> So, I thought, I was following some wrong approach and to retain the File
> Descriptors for a long enough period across scopes, I may need the
> DescriptorPool, which might have the permanent lifetime for the period of
> the application.
>
>
>
> Hi Jason:
>
> I am always able to generate the FileDescriptorSet easily, although the
> FileDescriptor was never showing completely populated fields when debugging
> with Visual studio 2008 Express edition.
>
> I have attached the generated FileDescriptorSet 'dynProtoMessage.dsc' file
> along with the proto file containing the above messages with this mail. You
> can see even this dsc file (made with simple messages as in the attached
> proto file) does not load through DescriptorPool::BuildFile().
>
>
>
> This is the function I used to load DescriptorSet:
>
>
>
> void CMessageParser
> ::getMessagesFromDescriptorSet(constgoogle::protobuf::FileDescriptor**
> new_file_desc)
>
> {
>
> using namespace google::protobuf;
>
> using namespace google::protobuf::io;
>
> using namespace google::protobuf::compiler;
>
> ifstream desc_file("dynProtoMessage.dsc",ios::in);
>
> if (desc_file.bad()) {
>
> std::cout << "desc file not read...exiting" <<
> std::endl;
>
> return;
>
> }
>
>
>
> FileDescriptorSet f;
>
> f.ParseFromIstream(&desc_file);
>
>
>
>// DescriptorPoolErrorCollector errorCol;
> //google::protobuf::SimpleDescriptorDatabase desc_database;
>//DescriptorPool descriptor_pool(&errorCol, &desc_database);
>
> DescriptorPool descriptor_pool;
>
> for (int i = 0; i < f.file_size(); ++i) {
>
> descriptor_pool.BuildFile(f.file(i));
>
> }
>
>
> const Descriptor* descriptor =
> descriptor_pool.FindMessageTypeByName("RecordHeader");
> // descriptor =>NULL here
>
> //const FileDescriptor* new_file_desc =
> descriptor_pool.FindFileByName("dynMessage.dsc");
> /*
> DynamicMessageFactory factory;
>
> Message* my_message = factory.GetPrototype(descriptor)->New();
> delete my_message;
>*/
>
>
>
> }
>
>
> Finally, the point raised by Kenton and you that the proto file did not
> parse correctly to yield the valid FileDescriptor might be correct, since, I
> am generating the .proto file containing the messages on the fly by
> converting corresponding tags from my XML file.
> When earlier I used a handmade proto file for the messages, which parsed
> correctly to provide the descriptors, I was able to stream data into
> protocol buffers and use the buffers correctly. I will be inspecti
Re: [protobuf] DescriptorPool::BuildFile() seems not parsing nested messages in order
On Thu, Sep 23, 2010 at 2:40 AM, Himanshu Srivastava wrote:
> Kenton:
>
>
> I really sent you a only a part of the complete RecordHeader message, since
> I was focusing on "nested message not getting parsed" issue for this
> particular message. Indeed my complete proto file is a large one. I have
> attached the truncated proto file containing this complete message only
> for reference with this mail (plese see attachment
> 'dynamicProtoMessages.proto '.
>
> I had used Parser and Importer earlier and generated the FileDescriptor in
> a class “CMessageParser” member function as below:
>
>
>
> //***//
>
> class PacketTracerErrorFileErrorCollector:
> publicgoogle::protobuf::compiler::MultiFileErrorCollector
>
> {
>
> ...
>
> };
>
>
>
>
>
> const google::protobuf::FileDescriptor* CMessageParser
> ::generateMessageFileDescriptor()
>
> {
>
> std::pair filePair;
>
> google::protobuf::compiler::DiskSourceTree source_tree;
>
> source_tree.MapPath(/*filePair.first*/"", "."/*filePair.second*/);
>
> PacketTracerErrorFileErrorCollector error_collector;//Defined above
>
> google::protobuf::compiler::Importer importer(&source_tree,
> &error_collector);
>
> std::string outFileNameString = “dynamicProtoMessages.proto”;
> const google::protobuf::FileDescriptor* file_desc =
> importer.Import(outFileNameString);
> return file_desc;
>
> }
>
> //***//
>
>
> However, the problem with that approach was, as soon as I returned the
> pointer from the FileDescriptor to a client class object of
> CMessageParser, the FileDescriptor* becomes NULL or invalid once out of
> the class and it becomes useless.
>
//***//
>
> CMessageParser myParser;
>
> const google::protobuf::FileDescriptor *file_desc =
> myParser.generateMessageFileDescriptor();
> //file_desc is NULL
>
> //***//
>
>
> So, I thought, I was following some wrong approach and to retain the File
> Descriptors for a long enough period across scopes, I may need the
> DescriptorPool, which might have the permanent lifetime for the period of
> the application.
>
Importer just wraps DescriptorPool and a database of proto files. Neither of
these guarantee static duration for the descriptors - any descriptors that
you build will only remain alive while the DescriptorPool/Importer remains
alive.
Of course, that means your code should seg-fault, not return NULL, assuming
that you successfully built the file. You should look at the error collector
to see what went wrong. I doubt that your code will work, as Importer should
be looking for a file named "dynamicProtoMessages.proto", which probably
does not exist.
But it sounds like you don't actually need to read .proto files, and instead
you are generating the *DescriptorProto representations directly. If that's
the case, you don't need Importer, you should directly use a DescriptorPool
as you did in the code snippet below.
>
>
> Hi Jason:
>
> I am always able to generate the FileDescriptorSet easily, although the
> FileDescriptor was never showing completely populated fields when debugging
> with Visual studio 2008 Express edition.
>
> I have attached the generated FileDescriptorSet 'dynProtoMessage.dsc' file
> along with the proto file containing the above messages with this mail. You
> can see even this dsc file (made with simple messages as in the attached
> proto file) does not load through DescriptorPool::BuildFile().
>
>
>
> This is the function I used to load DescriptorSet:
>
>
>
> void CMessageParser
> ::getMessagesFromDescriptorSet(constgoogle::protobuf::FileDescriptor**
> new_file_desc)
>
> {
>
> using namespace google::protobuf;
>
> using namespace google::protobuf::io;
>
> using namespace google::protobuf::compiler;
>
> ifstream desc_file("dynProtoMessage.dsc",ios::in);
>
> if (desc_file.bad()) {
>
> std::cout << "desc file not read...exiting" <<
> std::endl;
>
> return;
>
> }
>
>
>
> FileDescriptorSet f;
>
> f.ParseFromIstream(&desc_file);
>
>
>
>// DescriptorPoolErrorCollector errorCol;
> //google::protobuf::SimpleDescriptorDatabase desc_database;
>//DescriptorPool descriptor_pool(&errorCol, &desc_database);
>
> DescriptorPool descriptor_pool;
>
> for (int i = 0; i < f.file_size(); ++i) {
>
> descriptor_pool.BuildFile(f.file(i));
>
Did you check that these return non-null and don't have any errors?
> }
>
>
> const Descriptor* descriptor =
> descriptor_pool.FindMessageTypeByName("RecordHeader");
> // descriptor =>NULL here
>
You need to use the fully-qualified name to find the message type:
descriptor_pool.FindMessageTypeByName("traceFileMessagesProto.RecordHeader");
> //const FileDescriptor*
Re: [protobuf] DescriptorPool::BuildFile() seems not parsing nested messages in order
Hi Jason,
In code:
////
DescriptorPool descriptor_pool;
for (int i = 0; i < f.file_size(); ++i) {
descriptor_pool.BuildFile(f.file(i));
////
descriptor_pool is of course NULL.
And for the Importer approach my code does SEG-FAULT.
Further I do need conversion from proto file directly and also a static
FileDescriptor so that it can be passed around for construction of my new
messages in a recursive tree algorithm in another distinct class object.
I do not want the descriptor set approach, since that is only available when
protoc exe is present.
-
>>I doubt that your code will work, as Importer should be looking for a file
named "dynamicProtoMessages.proto", which probably >>does not exist.
I create the proto file "dynamicProtoMessages.proto" parmanently on disk and
read it from disk to Parser after it is generated from my
CXMLToProtoFileGenerator class.
Thanks & Regards,
Himanshu
On Thu, Sep 23, 2010 at 9:39 PM, Jason Hsueh wrote:
>
>
> On Thu, Sep 23, 2010 at 2:40 AM, Himanshu Srivastava
> wrote:
>
>> Kenton:
>>
>>
>> I really sent you a only a part of the complete RecordHeader message,
>> since I was focusing on "nested message not getting parsed" issue for this
>> particular message. Indeed my complete proto file is a large one. I have
>> attached the truncated proto file containing this complete message only
>> for reference with this mail (plese see attachment
>> 'dynamicProtoMessages.proto '.
>>
>> I had used Parser and Importer earlier and generated the FileDescriptor in
>> a class “CMessageParser” member function as below:
>>
>>
>>
>> //***//
>>
>> class PacketTracerErrorFileErrorCollector:
>> publicgoogle::protobuf::compiler::MultiFileErrorCollector
>>
>> {
>>
>> ...
>>
>> };
>>
>>
>>
>>
>>
>> const google::protobuf::FileDescriptor* CMessageParser
>> ::generateMessageFileDescriptor()
>>
>> {
>>
>> std::pair filePair;
>>
>> google::protobuf::compiler::DiskSourceTree source_tree;
>>
>> source_tree.MapPath(/*filePair.first*/"", "."/*filePair.second*/);
>>
>> PacketTracerErrorFileErrorCollector error_collector;//Defined above
>>
>> google::protobuf::compiler::Importer importer(&source_tree,
>> &error_collector);
>>
>> std::string outFileNameString = “dynamicProtoMessages.proto”;
>> const google::protobuf::FileDescriptor* file_desc =
>> importer.Import(outFileNameString);
>> return file_desc;
>>
>> }
>>
>> //***//
>>
>>
>> However, the problem with that approach was, as soon as I returned the
>> pointer from the FileDescriptor to a client class object of
>> CMessageParser, the FileDescriptor* becomes NULL or invalid once out of
>> the class and it becomes useless.
>>
> //***//
>>
>> CMessageParser myParser;
>>
>> const google::protobuf::FileDescriptor *file_desc =
>> myParser.generateMessageFileDescriptor();
>> //file_desc is NULL
>>
>> //***//
>>
>>
>> So, I thought, I was following some wrong approach and to retain the File
>> Descriptors for a long enough period across scopes, I may need the
>> DescriptorPool, which might have the permanent lifetime for the period of
>> the application.
>>
>
> Importer just wraps DescriptorPool and a database of proto files. Neither
> of these guarantee static duration for the descriptors - any descriptors
> that you build will only remain alive while the DescriptorPool/Importer
> remains alive.
>
> Of course, that means your code should seg-fault, not return NULL, assuming
> that you successfully built the file. You should look at the error collector
> to see what went wrong. I doubt that your code will work, as Importer should
> be looking for a file named "dynamicProtoMessages.proto", which probably
> does not exist.
>
> But it sounds like you don't actually need to read .proto files, and
> instead you are generating the *DescriptorProto representations directly. If
> that's the case, you don't need Importer, you should directly use a
> DescriptorPool as you did in the code snippet below.
>
>
>>
>>
>> Hi Jason:
>>
>> I am always able to generate the FileDescriptorSet easily, although the
>> FileDescriptor was never showing completely populated fields when debugging
>> with Visual studio 2008 Express edition.
>>
>> I have attached the generated FileDescriptorSet 'dynProtoMessage.dsc' file
>> along with the proto file containing the above messages with this mail. You
>> can see even this dsc file (made with simple messages as in the attached
>> proto file) does not load through DescriptorPool::BuildFile().
>>
>>
>>
>> This is the function I used to load DescriptorSet:
>>
>>
>>
>> void CMessageParser
>> ::getMessagesFromDescriptorSet(constgoogl
Re: [protobuf] DescriptorPool::BuildFile() seems not parsing nested messages in order
Hi Jason,
The modules all seem to work now as soon as I created the Importer on the
heap and the FileDescriptor is also available across scopes.
I need to follow the algorithm to see all messages are getting instanciated.
Thanks for your quick help.
Thanks & Regards,
Himanshu
On Thu, Sep 23, 2010 at 10:22 PM, Himanshu Srivastava wrote:
> Hi Jason,
>
> In code:
> ////
> DescriptorPool descriptor_pool;
>
> for (int i = 0; i < f.file_size(); ++i) {
>
> descriptor_pool.BuildFile(f.file(i));
> ////
> descriptor_pool is of course NULL.
>
> And for the Importer approach my code does SEG-FAULT.
>
> Further I do need conversion from proto file directly and also a static
> FileDescriptor so that it can be passed around for construction of my new
> messages in a recursive tree algorithm in another distinct class object.
>
> I do not want the descriptor set approach, since that is only available
> when protoc exe is present.
> -
> >>I doubt that your code will work, as Importer should be looking for a
> file named "dynamicProtoMessages.proto", which probably >>does not exist.
>
> I create the proto file "dynamicProtoMessages.proto" parmanently on disk
> and read it from disk to Parser after it is generated from my
> CXMLToProtoFileGenerator class.
>
>
> Thanks & Regards,
> Himanshu
>
>
> On Thu, Sep 23, 2010 at 9:39 PM, Jason Hsueh wrote:
>
>>
>>
>> On Thu, Sep 23, 2010 at 2:40 AM, Himanshu Srivastava > > wrote:
>>
>>> Kenton:
>>>
>>>
>>> I really sent you a only a part of the complete RecordHeader message,
>>> since I was focusing on "nested message not getting parsed" issue for this
>>> particular message. Indeed my complete proto file is a large one. I have
>>> attached the truncated proto file containing this complete message only
>>> for reference with this mail (plese see attachment
>>> 'dynamicProtoMessages.proto '.
>>>
>>> I had used Parser and Importer earlier and generated the FileDescriptor
>>> in a class “CMessageParser” member function as below:
>>>
>>>
>>>
>>> //***//
>>>
>>> class PacketTracerErrorFileErrorCollector:
>>> publicgoogle::protobuf::compiler::MultiFileErrorCollector
>>>
>>> {
>>>
>>> ...
>>>
>>> };
>>>
>>>
>>>
>>>
>>>
>>> const google::protobuf::FileDescriptor* CMessageParser
>>> ::generateMessageFileDescriptor()
>>>
>>> {
>>>
>>> std::pair filePair;
>>>
>>> google::protobuf::compiler::DiskSourceTree source_tree;
>>>
>>> source_tree.MapPath(/*filePair.first*/"", "."/*filePair.second*/);
>>>
>>> PacketTracerErrorFileErrorCollector error_collector;//Defined above
>>>
>>> google::protobuf::compiler::Importer importer(&source_tree,
>>> &error_collector);
>>>
>>> std::string outFileNameString = “dynamicProtoMessages.proto”;
>>> const google::protobuf::FileDescriptor* file_desc =
>>> importer.Import(outFileNameString);
>>> return file_desc;
>>>
>>> }
>>>
>>> //***//
>>>
>>>
>>> However, the problem with that approach was, as soon as I returned the
>>> pointer from the FileDescriptor to a client class object of
>>> CMessageParser, the FileDescriptor* becomes NULL or invalid once out
>>> of the class and it becomes useless.
>>>
>> //***//
>>>
>>> CMessageParser myParser;
>>>
>>> const google::protobuf::FileDescriptor *file_desc =
>>> myParser.generateMessageFileDescriptor();
>>> //file_desc is NULL
>>>
>>> //***//
>>>
>>>
>>> So, I thought, I was following some wrong approach and to retain the
>>> File Descriptors for a long enough period across scopes, I may need the
>>> DescriptorPool, which might have the permanent lifetime for the period of
>>> the application.
>>>
>>
>> Importer just wraps DescriptorPool and a database of proto files. Neither
>> of these guarantee static duration for the descriptors - any descriptors
>> that you build will only remain alive while the DescriptorPool/Importer
>> remains alive.
>>
>> Of course, that means your code should seg-fault, not return NULL,
>> assuming that you successfully built the file. You should look at the error
>> collector to see what went wrong. I doubt that your code will work, as
>> Importer should be looking for a file named "dynamicProtoMessages.proto",
>> which probably does not exist.
>>
>> But it sounds like you don't actually need to read .proto files, and
>> instead you are generating the *DescriptorProto representations directly. If
>> that's the case, you don't need Importer, you should directly use a
>> DescriptorPool as you did in the code snippet below.
>>
>>
>>>
>>>
>>> Hi Jason:
>>>
>>> I am always able to generate the FileDescriptorSet easily, although the
>>> FileDescriptor was never showing completely populate
[protobuf] Re: Issue 220 in protobuf: TextFormat:Parser cannot parse strings with colon?
Comment #4 on issue 220 by temporal: TextFormat:Parser cannot parse strings with colon? http://code.google.com/p/protobuf/issues/detail?id=220 No problem, happens to the best of us. -- 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: [protobuf] DescriptorPool::BuildFile() seems not parsing nested messages in order
On Thu, Sep 23, 2010 at 9:52 AM, Himanshu Srivastava wrote:
> Hi Jason,
>
> In code:
> ////
> DescriptorPool descriptor_pool;
>
> for (int i = 0; i < f.file_size(); ++i) {
>
> descriptor_pool.BuildFile(f.file(i));
> ////
> descriptor_pool is of course NULL.
>
I meant that you should check the return value of BuildFile(). If it returns
NULL, then it could not build the file. The ErrorCollector would tell you
why.
> And for the Importer approach my code does SEG-FAULT.
>
> Further I do need conversion from proto file directly and also a static
> FileDescriptor so that it can be passed around for construction of my new
> messages in a recursive tree algorithm in another distinct class object.
>
That's up to you: you'll need to ensure that the DescriptorPool has the
lifetime you want.
Previously, you mentioned that the importer approach returned NULL. That
would be indicative of a problem in the .proto file: the file could not be
built. Even if you were to successfully build the file, your code would
segfault, because the FileDescriptor is no longer valid, as the Importer,
and thus the DescriptorPool containing the FileDescriptor, have been
deleted.
>
> I do not want the descriptor set approach, since that is only available
> when protoc exe is present.
> -
> >>I doubt that your code will work, as Importer should be looking for a
> file named "dynamicProtoMessages.proto", which probably >>does not exist.
>
> I create the proto file "dynamicProtoMessages.proto" parmanently on disk
> and read it from disk to Parser after it is generated from my
> CXMLToProtoFileGenerator class.
>
Gotcha. If you run protoc on the file produced by your generator class, does
it succeed?
>
> Thanks & Regards,
> Himanshu
>
>
> On Thu, Sep 23, 2010 at 9:39 PM, Jason Hsueh wrote:
>
>>
>>
>> On Thu, Sep 23, 2010 at 2:40 AM, Himanshu Srivastava > > wrote:
>>
>>> Kenton:
>>>
>>>
>>> I really sent you a only a part of the complete RecordHeader message,
>>> since I was focusing on "nested message not getting parsed" issue for this
>>> particular message. Indeed my complete proto file is a large one. I have
>>> attached the truncated proto file containing this complete message only
>>> for reference with this mail (plese see attachment
>>> 'dynamicProtoMessages.proto '.
>>>
>>> I had used Parser and Importer earlier and generated the FileDescriptor
>>> in a class “CMessageParser” member function as below:
>>>
>>>
>>>
>>> //***//
>>>
>>> class PacketTracerErrorFileErrorCollector:
>>> publicgoogle::protobuf::compiler::MultiFileErrorCollector
>>>
>>> {
>>>
>>> ...
>>>
>>> };
>>>
>>>
>>>
>>>
>>>
>>> const google::protobuf::FileDescriptor* CMessageParser
>>> ::generateMessageFileDescriptor()
>>>
>>> {
>>>
>>> std::pair filePair;
>>>
>>> google::protobuf::compiler::DiskSourceTree source_tree;
>>>
>>> source_tree.MapPath(/*filePair.first*/"", "."/*filePair.second*/);
>>>
>>> PacketTracerErrorFileErrorCollector error_collector;//Defined above
>>>
>>> google::protobuf::compiler::Importer importer(&source_tree,
>>> &error_collector);
>>>
>>> std::string outFileNameString = “dynamicProtoMessages.proto”;
>>> const google::protobuf::FileDescriptor* file_desc =
>>> importer.Import(outFileNameString);
>>> return file_desc;
>>>
>>> }
>>>
>>> //***//
>>>
>>>
>>> However, the problem with that approach was, as soon as I returned the
>>> pointer from the FileDescriptor to a client class object of
>>> CMessageParser, the FileDescriptor* becomes NULL or invalid once out
>>> of the class and it becomes useless.
>>>
>> //***//
>>>
>>> CMessageParser myParser;
>>>
>>> const google::protobuf::FileDescriptor *file_desc =
>>> myParser.generateMessageFileDescriptor();
>>> //file_desc is NULL
>>>
>>> //***//
>>>
>>>
>>> So, I thought, I was following some wrong approach and to retain the
>>> File Descriptors for a long enough period across scopes, I may need the
>>> DescriptorPool, which might have the permanent lifetime for the period of
>>> the application.
>>>
>>
>> Importer just wraps DescriptorPool and a database of proto files. Neither
>> of these guarantee static duration for the descriptors - any descriptors
>> that you build will only remain alive while the DescriptorPool/Importer
>> remains alive.
>>
>> Of course, that means your code should seg-fault, not return NULL,
>> assuming that you successfully built the file. You should look at the error
>> collector to see what went wrong. I doubt that your code will work, as
>> Importer should be looking for a file named "dynamicProtoMessages.proto",
>> which probably does not exist.
>>
>> But
[protobuf] Issue 221 in protobuf: Minor issue: Warning in coded_stream.h using gcc 3.4.6
Status: New Owner: ken...@google.com Labels: Type-Defect Priority-Medium New issue 221 by gerd94706: Minor issue: Warning in coded_stream.h using gcc 3.4.6 http://code.google.com/p/protobuf/issues/detail?id=221 What steps will reproduce the problem? 1. find a system that uses gcc 3.4.6 (others may display the same issue) 2. compile code (-Wall) that somehow ends up #includ'ing coded_stream.h 3. observe the warning What is the expected output? What do you see instead? No warning (ideally) What version of the product are you using? On what operating system? Red Hat Enterprise Linux AS release 4 Please provide any additional information below. The result of BufferSize() (of type int) is compared with sizeof(*value) (of type size_t). gcc 3.4.6 complains about comparing signed with an unsigned. I suggest to either cast the sizeof operator to int ((int) sizeof(*value)) or to make BufferSize return size_t. Proposed fix is attached. Attachments: protoc-warnings-diff.txt 981 bytes -- 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.
[protobuf] Re: Issue 221 in protobuf: Minor issue: Warning in coded_stream.h using gcc 3.4.6
Updates: Status: Duplicate Owner: --- Comment #1 on issue 221 by jas...@google.com: Minor issue: Warning in coded_stream.h using gcc 3.4.6 http://code.google.com/p/protobuf/issues/detail?id=221 This was fixed in r302: http://code.google.com/p/protobuf/source/detail?r=302 -- 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.
