On Fri, Oct 9, 2015 at 10:51 AM, Walter Schulze <[email protected]>
wrote:
> In other words C# and those new languages won't be able to serialize the
> descriptor?
>
descriptor.proto is an exception. It's allowed to be imported by proto3
files to support custom options. I.e., the following is explicitly allowed:
syntax = "proto3";
package test;
*import "google/protobuf/descriptor.proto";*
*extend google.protobuf.FieldOptions {*
* string my_field_option = 123456789;*
*}*
message TestMessage {
int32 value = 1 [*(my_field_option) = "Some extra option data"*];
}
However, the ability to use these descriptor info at run-time may be
limited (or not present) in certain languages. It depends on what API is
provided by the specific language. +Jon Skeet could probably say more about
how to use/access descriptors in C#.
>
> On 9 October 2015 at 19:44, 'Feng Xiao' via Protocol Buffers <
> [email protected]> wrote:
>
>> The decision is not to support proto2 in C# (and probably also for all
>> other languages that are new in v3.0.0+).
>>
>> On Fri, Oct 9, 2015 at 10:42 AM, Teddy Zhang <[email protected]>
>> wrote:
>>
>>> Will the C# implementation support proto2 message as well?
>>> What is the compatibility story between proto2 and proto 3? I assume the
>>> wire format is compatible as long as no proto 3 exclusive features are used.
>>>
>>>
>>> On Tuesday, August 4, 2015 at 5:43:36 AM UTC-7, Jon Skeet wrote:
>>>
>>>> That looks like you're expecting a protobuf.net-style approach - to
>>>> which the answer is "no" and will continue to be "no".
>>>>
>>>> The C# support will continue to be based on generated code, but there's
>>>> a new code generator and runtime now in the master branch. The main changes
>>>> from the previous code are:
>>>>
>>>> - proto3-only support (no proto2 at all)
>>>> - mutable generated types rather than the Java-style builders and
>>>> immutable messages
>>>>
>>>> Jon
>>>>
>>>> On Monday, 3 August 2015 22:50:06 UTC+1, The Nguyen Xuan wrote:
>>>>>
>>>>> Does this version support object type in C# ?
>>>>>
>>>>> ex:
>>>>>
>>>>> [ProtoMember(1)]
>>>>> public object A {get;set;}
>>>>>
>>>>> thank.
>>>>>
>>>>> Vào 11:51:01 UTC+7 Thứ Năm, ngày 11 tháng 12 năm 2014, Feng Xiao đã
>>>>> viết:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I just published protobuf v3.0.0-alpha-1 on our github site:
>>>>>> https://github.com/google/protobuf/releases/tag/v3.0.0-alpha-1
>>>>>>
>>>>>> This is the first alpha release of protobuf v3.0.0. In protobuf
>>>>>> v3.0.0, we will add a new protobuf language version (aka proto3) and
>>>>>> support a wider range of programming languages (to name a few: ruby, php,
>>>>>> node.js, objective-c). This alpha version contains C++ and Java
>>>>>> implementation with partial proto3 support (see below for details). In
>>>>>> future releases we will add support for more programming languages and
>>>>>> implement the full proto3 feature set. Besides proto3, this alpha version
>>>>>> also includes two other new features: map fields and arena allocation.
>>>>>> They
>>>>>> are implemented for both proto3 and the old protobuf language version
>>>>>> (aka
>>>>>> proto2).
>>>>>>
>>>>>> We are currently working on the documentation of these new features
>>>>>> and when it's ready it will be updated to our protobuf developer
>>>>>> guide <https://developers.google.com/protocol-buffers/docs/overview>.
>>>>>> For the time being if you have any questions regarding proto3 or other
>>>>>> new
>>>>>> features, please post your question in the discussion group.
>>>>>>
>>>>>> CHANGS
>>>>>> =======
>>>>>> Version 3.0.0-alpha-1 (C++/Java):
>>>>>>
>>>>>> General
>>>>>> * Introduced Protocol Buffers language version 3 (aka proto3).
>>>>>>
>>>>>> When protobuf was initially opensourced it implemented Protocol
>>>>>> Buffers
>>>>>> language version 2 (aka proto2), which is why the version number
>>>>>> started from v2.0.0. From v3.0.0, a new language version (proto3)
>>>>>> is
>>>>>> introduced while the old version (proto2) will continue to be
>>>>>> supported.
>>>>>>
>>>>>> The main intent of introducing proto3 is to clean up protobuf
>>>>>> before
>>>>>> pushing the language as the foundation of Google's new API
>>>>>> platform.
>>>>>> In proto3, the language is simplified, both for ease of use and
>>>>>> to
>>>>>> make it available in a wider range of programming languages. At
>>>>>> the
>>>>>> same time a few features are added to better support common idioms
>>>>>> found in APIs.
>>>>>>
>>>>>> The following are the main new features in language version 3:
>>>>>>
>>>>>> 1. Removal of field presence logic for primitive value fields,
>>>>>> removal
>>>>>> of required fields, and removal of default values. This
>>>>>> makes proto3
>>>>>> significantly easier to implement with open struct
>>>>>> representations,
>>>>>> as in languages like Android Java, Objective C, or Go.
>>>>>> 2. Removal of unknown fields.
>>>>>> 3. Removal of extensions, which are instead replaced by a new
>>>>>> standard
>>>>>> type called Any.
>>>>>> 4. Fix semantics for unknown enum values.
>>>>>> 5. Addition of maps.
>>>>>> 6. Addition of a small set of standard types for representation
>>>>>> of time,
>>>>>> dynamic data, etc.
>>>>>> 7. A well-defined encoding in JSON as an alternative to binary
>>>>>> proto
>>>>>> encoding.
>>>>>>
>>>>>> This release (v3.0.0-alpha-1) includes partial proto3 support for
>>>>>> C++ and
>>>>>> Java. Items 6 (well-known types) and 7 (JSON format) in the above
>>>>>> feature
>>>>>> list are not implemented.
>>>>>>
>>>>>> A new notion "syntax" is introduced to specify whether a .proto
>>>>>> file
>>>>>> uses proto2 or proto3:
>>>>>>
>>>>>> // foo.proto
>>>>>> syntax = "proto3";
>>>>>> message Bar {...}
>>>>>>
>>>>>> If omitted, the protocol compiler will generate a warning and
>>>>>> "proto2" will
>>>>>> be used as the default. This warning will be turned into an error
>>>>>> in a
>>>>>> future release.
>>>>>>
>>>>>> We recommend that new Protocol Buffers users use proto3. However,
>>>>>> we do not
>>>>>> generally recommend that existing users migrate from proto2 from
>>>>>> proto3 due
>>>>>> to API incompatibility, and we will continue to support proto2
>>>>>> for a long
>>>>>> time.
>>>>>>
>>>>>> * Added support for map fields (implemented in C++/Java for both
>>>>>> proto2 and
>>>>>> proto3).
>>>>>>
>>>>>> Map fields can be declared using the following syntax:
>>>>>>
>>>>>> message Foo {
>>>>>> map<string, string> values = 1;
>>>>>> }
>>>>>>
>>>>>> Data of a map field will be stored in memory as an unordered map
>>>>>> and it
>>>>>> can be accessed through generated accessors.
>>>>>>
>>>>>> C++
>>>>>> * Added arena allocation support (for both proto2 and proto3).
>>>>>>
>>>>>> Profiling shows memory allocation and deallocation constitutes a
>>>>>> significant
>>>>>> fraction of CPU-time spent in protobuf code and arena allocation
>>>>>> is a
>>>>>> technique introduced to reduce this cost. With arena allocation,
>>>>>> new
>>>>>> objects will be allocated from a large piece of preallocated
>>>>>> memory and
>>>>>> deallocation of these objects is almost free. Early adoption
>>>>>> shows 20% to
>>>>>> 50% improvement in some Google binaries.
>>>>>>
>>>>>> To enable arena support, add the following option to your .proto
>>>>>> file:
>>>>>>
>>>>>> option cc_enable_arenas = true;
>>>>>>
>>>>>> Protocol compiler will generate additional code to make the
>>>>>> generated
>>>>>> message classes work with arenas. This does not change the
>>>>>> existing API
>>>>>> of protobuf messages and does not affect wire format. Your
>>>>>> existing code
>>>>>> should continue to work after adding this option. In the future
>>>>>> we will
>>>>>> make this option enabled by default.
>>>>>>
>>>>>> To actually take advantage of arena allocation, you need to use
>>>>>> the arena
>>>>>> APIs when creating messages. A quick example of using the arena
>>>>>> API:
>>>>>>
>>>>>> {
>>>>>> google::protobuf::Arena arena;
>>>>>> // Allocate a protobuf message in the arena.
>>>>>> MyMessage* message = Arena::CreateMessage<MyMessage>(&arena);
>>>>>> // All submessages will be allocated in the same arena.
>>>>>> if (!message->ParseFromString(data)) {
>>>>>> // Deal with malformed input data.
>>>>>> }
>>>>>> // Must not delete the message here. It will be deleted
>>>>>> automatically
>>>>>> // when the arena is destroyed.
>>>>>> }
>>>>>>
>>>>>> Currently arena does not work with map fields. Enabling arena in
>>>>>> a .proto
>>>>>> file containing map fields will result in compile errors in the
>>>>>> generated
>>>>>> code. This will be addressed in a future release.
>>>>>> =======
>>>>>>
>>>>>> Thanks,
>>>>>> Feng
>>>>>>
>>>>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Protocol Buffers" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/protobuf/ZRpcfmeGK6s/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> [email protected].
>> To post to this group, send email to [email protected].
>> Visit this group at http://groups.google.com/group/protobuf.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.
