Status: New
Owner: liuj...@google.com
Labels: Type-Defect Priority-Medium
New issue 382 by nn1436...@gmail.com: improving GOOGLE_ARRAYSIZE
http://code.google.com/p/protobuf/issues/detail?id=382
Current implementation is not good enough.
Use the following one:
template class T, int Size
char (
I am trying to follow the install instructions in the README. The
step states to run ./configure. When I execute it the process dies
with the message:
...
checking for nawk... nawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking whether the C compiler works... no
Hi,
I have a situation where I have proto definitions in a third-party foo.jar,
but I want to access the definitions from within my own project. In the
documentation for the proto_path flag, it only states multiple directories
in which to look for, with no mention of including jars on the
Hi all,
I am using protobuf 2.4.1, and I encountered a weird issue:
I created the following .proto file:
message Auction {
// Bid request id
required bytes Id = 1;
optional bytes Ip = 2;
required int32 adId = 3;
required int32 adHeight = 4;
How are you setting the data?
You should be using something like:
bid.set_HtmlSnippet(Stuff);
and
std::string html = bid.HtmlSnippet();
See:
https://developers.google.com/protocol-buffers/docs/reference/cpp/google.protobuf.message
On Wednesday, April 4, 2012 7:25:15 AM UTC-5, G. wrote:
Hi
Any plans to provide out-of-the-box for commonly used data types such
as Date (encoded as String) and BigDecimal/BigInteger types? Seems
this would be of interest to a lot of users.
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to
proto files are mapped to many languages, Date and BigDecimal are java
specific.
On Apr 4, 2012, at 9:37 AM, jhakim wrote:
Any plans to provide out-of-the-box for commonly used data types such
as Date (encoded as String) and BigDecimal/BigInteger types? Seems
this would be of interest to a
What would be the mapping for C or C++? I think there is an advantage of
keeping the set of data types very limited, to primitive values which can be
easily mapped to multiple languages.
Otherwise things can get complicated. Let's take date as an example. It's
representation depends on the
Date and decimal types are ubiquitous and in wide use. Language specific
bindings could easily be created - this is exactly what we do in some other
open source projects that I contribute to. The way I envision it, protocol
buffers would provide 'date' and 'decimal' types - protoc compiler
You are correct to point out the complications of dealing with complex data
types. All the more reason why it would be great to not have the developer
community keep re-inventing the wheel. But I understand why this is not on the
radar map of the proto buffer team.
My group builds applications
AFAIK the answer is no. A lot of the value of protocol buffers derives from
keeping their functionality simple. There are plenty of all singing/all dancing
serialization frameworks already. ;-)
I think date in particular is fraught with peril. I'd recommend against
encodung them as strings.
Nothing prevents you from making a module available for everyone's benefit. If
it is broadly useful, it will undoubtedly be universally adopted.
--Chris
P.S.: What is a decimal type?
On Apr 4, 2012, at 2:21 PM, Jawaid Hakim jawaid.ha...@codestreet.com wrote:
Date and decimal types are
On Apr 4, 2012, at 2:54 PM, Jawaid Hakim jawaid.ha...@codestreet.com wrote:
My group builds applications using use multiple languages, including Java and
C#, so a simple int64 for date representation does not work.
That there isn't a simple way to do it is a pretty nasty strike against
13 matches
Mail list logo
