[protobuf] Max number of repeated fields

2014-01-30 Thread Øyvind Bakken
We have a protobuf message defined in the following way:

message ModuleEntry 
{
optional uint32 id = 1;
optional string name = 2;
optional uint32 type = 3;
repeated ParameterEntry parameter = 4;
repeated ModuleEntry subModules = 5;
optional uint32 usage = 6;
optional string description = 7;
}

The message ModuleEntry can include several other ModuleEntrys 
(submodules). One of these submodules can again include several 
ParameterEntrys:

message ParameterEntry
{
required uint32 id = 1;
optional ParameterDataType dataType = 2;
optional ParameterType type = 3 [default = MEASUREMENT];
optional string name = 4;
optional int32 integerData = 5;
optional double doubleData = 6;
optional string unit = 7;

enum DynamicSimulation
{
STATIC = 0;
DYNAMIC = 1;
}
enum ParameterType
{
MEASUREMENT = 0;
CONFIGURABLE = 1;
INPUT = 2;
}
}

Our issue is appearing when we are increasing the number of ParameterEntrys 
for a submodule over a certain limit (from 18 to 19). The program then 
crashes with the following error message:

 libprotobuf FATAL ../build/include/google/protobuf/repeated_field.h:659] 
CHECK failed: (index)  (size()): terminate called after throwing an 
instance of 'google::protobuf::FatalException'

what(): CHECK failed: (index)  (size()): 

I have searched our code to find if we have set any constraints on array 
size or similar, but it does not seem so. Is there any limitation to 
Protobuf that is causing this behavior, i.e. a max number of repeated 
fields? It seems that the number of repeated fields for messages that are 
not submodules can be higher though, without crashes occuring. Also, 
decreasing the number of the given submodule, or the number of its parent 
module (to decrease the total data size) have no effect.


We are using Protobuf version 2.4.1. (I guess this version is kind of 
outdated, is it recommendable to upgrade to the latest version?)


Regards

-- 
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [protobuf] Max number of repeated fields

2014-01-30 Thread Feng Xiao
On Thu, Jan 30, 2014 at 6:48 AM, Øyvind Bakken oyv...@gmail.com wrote:

 We have a protobuf message defined in the following way:

 message ModuleEntry
 {
 optional uint32 id = 1;
 optional string name = 2;
 optional uint32 type = 3;
 repeated ParameterEntry parameter = 4;
 repeated ModuleEntry subModules = 5;
 optional uint32 usage = 6;
 optional string description = 7;
 }

 The message ModuleEntry can include several other ModuleEntrys
 (submodules). One of these submodules can again include several
 ParameterEntrys:

 message ParameterEntry
 {
 required uint32 id = 1;
 optional ParameterDataType dataType = 2;
 optional ParameterType type = 3 [default = MEASUREMENT];
 optional string name = 4;
 optional int32 integerData = 5;
 optional double doubleData = 6;
 optional string unit = 7;

 enum DynamicSimulation
 {
 STATIC = 0;
 DYNAMIC = 1;
 }
 enum ParameterType
 {
 MEASUREMENT = 0;
 CONFIGURABLE = 1;
 INPUT = 2;
 }
 }

 Our issue is appearing when we are increasing the number of
 ParameterEntrys for a submodule over a certain limit (from 18 to 19). The
 program then crashes with the following error message:

 libprotobuf FATAL ../build/include/google/protobuf/repeated_field.h:659]
 CHECK failed: (index)  (size()): terminate called after throwing an
 instance of 'google::protobuf::FatalException'

 what(): CHECK failed: (index)  (size()):

You should check the stack trace and see why it's called with an
out-of-band index.




 I have searched our code to find if we have set any constraints on array
 size or similar, but it does not seem so. Is there any limitation to
 Protobuf that is causing this behavior, i.e. a max number of repeated
 fields?

There is no such limit in protobuf.


 It seems that the number of repeated fields for messages that are not
 submodules can be higher though, without crashes occuring. Also, decreasing
 the number of the given submodule, or the number of its parent module (to
 decrease the total data size) have no effect.


 We are using Protobuf version 2.4.1. (I guess this version is kind of
 outdated, is it recommendable to upgrade to the latest version?)


 Regards

  --
 You received this message because you are subscribed to the Google Groups
 Protocol Buffers group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to protobuf+unsubscr...@googlegroups.com.
 To post to this group, send email to protobuf@googlegroups.com.
 Visit this group at http://groups.google.com/group/protobuf.
 For more options, visit https://groups.google.com/groups/opt_out.


-- 
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/groups/opt_out.


[protobuf] Re: Issue 515 in protobuf: More intelligent enums

2014-01-30 Thread protobuf


Comment #1 on issue 515 by joew...@live.com: More intelligent enums
http://code.google.com/p/protobuf/issues/detail?id=515

I would say the option name is a little language specific, but the idea is  
good.  Maybe call it scoped=true or something similar and add a  
command-line protoc flag to make it the default.  I would also like to see  
the option to generate C++11 enum classes too, so the namespace feature  
would just be used for backwards compatibility for older C++ compilers.


--
You received this message because this project is configured to send all  
issue notifications to this address.

You may adjust your notification preferences at:
https://code.google.com/hosting/settings

--
You received this message because you are subscribed to the Google Groups Protocol 
Buffers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/groups/opt_out.


[protobuf] Re: Issue 515 in protobuf: More intelligent enums

2014-01-30 Thread protobuf


Comment #2 on issue 515 by xiaof...@google.com: More intelligent enums
http://code.google.com/p/protobuf/issues/detail?id=515

The proposed solution doesn't work because:
1. The name of the enum type is changed from Foo to Foo::Enum which  
will be confusing to the users.
2. For enums nested in a message you simply can't nest a namespace in a  
class.


The current scoping semantics is a design choice made a long time ago and  
the value of allowing duplicated enum value names is also very limited. It  
doesn't seem to be a worthwhile effort to me.


--
You received this message because this project is configured to send all  
issue notifications to this address.

You may adjust your notification preferences at:
https://code.google.com/hosting/settings

--
You received this message because you are subscribed to the Google Groups Protocol 
Buffers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/groups/opt_out.


[protobuf] Re: Issue 515 in protobuf: More intelligent enums

2014-01-30 Thread protobuf


Comment #3 on issue 515 by kara...@gmail.com: More intelligent enums
http://code.google.com/p/protobuf/issues/detail?id=515

Instead of `namespace Bar { enum ...`, we could use `enum class Bar ...',  
or perhaps `struct Bar { enum ...`.


For myself, I don't care much about duplicated enum value names, but I  
would certainly like to use scoped enums for style and clarity reasons.


I suppose the reasons for adding something like this to protobuf would be  
similar to the reasons for why `enum class` was recently added to C++.


--
You received this message because this project is configured to send all  
issue notifications to this address.

You may adjust your notification preferences at:
https://code.google.com/hosting/settings

--
You received this message because you are subscribed to the Google Groups Protocol 
Buffers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/groups/opt_out.


[protobuf] Re: Issue 515 in protobuf: More intelligent enums

2014-01-30 Thread protobuf


Comment #4 on issue 515 by xiaof...@google.com: More intelligent enums
http://code.google.com/p/protobuf/issues/detail?id=515

I think the support for C++11 enum class is a good feature to have. We'll  
need to wait for some time though, as we currently still prohibit C++11  
features in protobuf.


--
You received this message because this project is configured to send all  
issue notifications to this address.

You may adjust your notification preferences at:
https://code.google.com/hosting/settings

--
You received this message because you are subscribed to the Google Groups Protocol 
Buffers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/groups/opt_out.


[protobuf] Re: Issue 515 in protobuf: More intelligent enums

2014-01-30 Thread protobuf


Comment #5 on issue 515 by cbsm...@gmail.com: More intelligent enums
http://code.google.com/p/protobuf/issues/detail?id=515

Why not put it in now with a flag or an #ifdef on the C++ version?

--
You received this message because this project is configured to send all  
issue notifications to this address.

You may adjust your notification preferences at:
https://code.google.com/hosting/settings

--
You received this message because you are subscribed to the Google Groups Protocol 
Buffers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/groups/opt_out.


[protobuf] Re: Issue 515 in protobuf: More intelligent enums

2014-01-30 Thread protobuf


Comment #6 on issue 515 by xiaof...@google.com: More intelligent enums
http://code.google.com/p/protobuf/issues/detail?id=515

Disallowing C++11 features is more of a policy issue rather than a  
technical one. The policy will eventually change but so far I haven't seen  
any move in that direction.


--
You received this message because this project is configured to send all  
issue notifications to this address.

You may adjust your notification preferences at:
https://code.google.com/hosting/settings

--
You received this message because you are subscribed to the Google Groups Protocol 
Buffers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/groups/opt_out.